Four software development guidelines
The only thing I hate worse than making mistakes, is repeating a mistake. Yesterday I was working through a very frustrating set of circumstances and had gotten myself micro-focused. This is a mental equivalence of painting oneself in the corner. Bassil Karam, one of the coolest guys you will ever meet and a very talented programmer, helped me out of my mental hole. I made several problem solving mistakes and I want to share them with others.
I am writing this as my personal penance. Maybe next time I'll shift my tactics a little sooner. So, without further preamble:
Rule 1: Don't fall in love with a solution
There's more than one way to skin a Cat. If your simple solution turns out to be a whole lot more complex than you intended, it is time to brainstorm some other solutions. Even if you return to your original solution, you can gain a new perspective by forcing yourself to think of alternative paths.
Rule 2: Don't Fight complexity with complexity
All things being equal, the simplest solution tends to be the right one.
Rule 3:Identify the true problem
"Any software problem can be solved by adding another layer of indirection. Except, of course, the problem of too much indirection." - Steve Bellovin of AT&T Labs
If you find yourself continuously adding indirection, maybe you should step back and regroup.
Rule 4: Regroup and use a small unencumbered test case to prove your solution.
While sometimes counter intuitive, building external test cases is an economical way to developing solutions.
Yesterday, I was solving a simple problem in a complicated environment. I was running behind, frustrated and convinced I had a working solution, if only it would work! Stepping outside that environment and building a test harness seemed like a waste of time when it would have really SAVED time. When you get stuck, stop, build the SMALLEST test case that proves the point, then proceed ahead with the regularly scheduled programming!
This is by no means an exhaustive list. If you have personal rules that help you develop solutions, please leave them in the comments for others to enjoy!
I'm all about KISS. The rock band rules too.
Rule 5: Learn to prototype.
The two ends of error are to go spec out an extensive solution without a proof of concept. OR to build the entire technology feature complete before proving it out. Prototypes don't do everything, they just show you are headed in the right direction before you get to the wrong location.
Rule 6: Dehydration
We don't dehydrate everything in the real world because only some foods lend themselves to benefit from dehydration. This in the code world is called Don't Repeat Yourself or DRY. Dry software doesn't just copy/paste/edit when it can be encapsulated. Without getting ultra OO you can benefit from DRY software development. Reuse moves edits to one location, makes life-cycle support better and often starts to make short term development faster and more stable.
Rule 7: QA
Test driven development can come in many forms. It should not just come from customer complaints! Nuff said on that.