My 5 Principles of Software

Posted At : April 9, 2006 5:32 PM | Posted By : Cameron
Related Categories: Standards

So, I've recently started a new job in the San Diego Biotech community. After being here for some time and watching how the corporate folks operate, I've decided to actually print out a few simple principles and tape them to my wall so that I can point at them (literally) when someone inevitably comes to me and asks me to do something in a way that makes me cringe. I didn't invent these sayings, I just like them, and find that they apply almost daily here in the office.

I thought I'd share the 5 things I currently have on my wall and see if anyone had any great additions:

  1. Work smarter, not harder.
  2. Do it right the first time, not the next time.
  3. Bring me your problem, not your solution.
  4. Never believe the vendor.
  5. There is always time for requirements.

Anyone else have anything posted on their wall? If so, what do you have up there?

Comments
[Add Comment]
Rob Brooks-Bilson's Gravatar Pick two: Good, Fast, Cheap.
# Posted By Rob Brooks-Bilson | 4/9/06 6:39 PM
Cameron Childress's Gravatar That's a good one too...
# Posted By Cameron Childress | 4/9/06 9:36 PM
Alistair Davidson's Gravatar Today's quick hack becomes tomorrow's critical system sooner than you realise
# Posted By Alistair Davidson | 4/10/06 1:35 AM
Brian Kotek's Gravatar If you don't have time to test up front, how will you have time to fix bugs later?
# Posted By Brian Kotek | 4/10/06 5:41 AM
yacoubean's Gravatar I'm curious what you mean with number 3. I think you mean that you hate it when people have incorrect solutions, and you'd rather they just tell you a problem and let you work it out. But I personally like it when people have a good solution, especially if it's a complex problem and I'd need guidance on how they want it fixed (like #5). I'm sorry, but #3 seems snotty and unprofessional to me.
# Posted By yacoubean | 4/10/06 6:59 AM
Mike Rankin's Gravatar The sooner the project schedule slips, the more time you'll have to make it up later ;)
# Posted By Mike Rankin | 4/10/06 7:26 AM
Cameron Childress's Gravatar yacoubean-

I really don't mind if someone suggests a sollution to me either. However, it's very common that a corporate user (non-developer) comes to the software develoment group with instructions for a software change that represents their solution. Sometimes corporate users don't even present the problem at all. This principle suggest to them that their solution may or may not be the correct solution and that they should be prepared to present the actual problem as well.

-Cameron
# Posted By Cameron Childress | 4/10/06 8:22 AM
Chris Velevitch's Gravatar Could you explain #5? Are you talking about XP/agile type of requirements or the all upfront type of requirements that are not allowed to change during the course of development?
# Posted By Chris Velevitch | 4/10/06 4:57 PM
Cameron Childress's Gravatar Chris-

When I say requirements, I'm talking about planning, documentation, and requirements in general. You'd have to figure out what this means for your specific situation, environment, and project.

-Cameron
# Posted By Cameron Childress | 4/10/06 5:27 PM
Jamie Haffey's Gravatar "Just because the system doesn't do what you want it to do, or even what you would expect it to do, doesn't necessarily mean that there is a bug in the system"

This is posted on my wall, and I have to point to it often.
# Posted By Jamie Haffey | 4/21/06 1:14 PM
[Add Comment]
    << October 2008 >>
    Sun Mon Tue Wed Thu Fri Sat
       1234
    5 6 7 8 9 10 11
    12 13 14 15 16 17 18
    19 20 21 22 23 24 25
    26 27 28 29 30 31  

Recent Entries

  • No recent entries.

Archives By Subject

Tech Blogs

(Mostly) Not Tech Blogs