My 5 Principles of Software

Posted By: Cameron Childress | April 9, 2006 5:32PM
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 (10)

[ Add Comment ]

Rob Brooks-Bilson Pick two: Good, Fast, Cheap.

# Posted By Rob Brooks-Bilson | April 9, 2006 6:39 PM

Cameron Childress That's a good one too...

# Posted By Cameron Childress | April 9, 2006 9:36 PM

Alistair Davidson Today's quick hack becomes tomorrow's critical system sooner than you realise

# Posted By Alistair Davidson | April 10, 2006 1:35 AM

Brian Kotek If you don't have time to test up front, how will you have time to fix bugs later?

# Posted By Brian Kotek | April 10, 2006 5:41 AM

yacoubean 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 | April 10, 2006 6:59 AM

Mike Rankin The sooner the project schedule slips, the more time you'll have to make it up later ;)

# Posted By Mike Rankin | April 10, 2006 7:26 AM

Cameron Childress 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 | April 10, 2006 8:22 AM

Chris Velevitch 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 | April 10, 2006 4:57 PM

Cameron Childress 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 | April 10, 2006 5:27 PM

Jamie Haffey "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 | April 21, 2006 1:14 PM

[ Add Comment ]

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)





Leave this field empty:

Categories

coldfusion misc user groups standards security technology flex adobe max sumo fitness coworkingatlanta commonspot version control travel svn robots that rock productivity music bluedragon air wireless san diego javascript webdirections vpn scalability mysql jobs fusebox etech cfeclipse

Recent Posts

Archives By Month