About Dan Wilson
Dan Wilson
Dan Wilson
Model-Glue:Gesture for Fun and Profit
Watch Video
Presentation Files
360 Flex Course
DataCurl LLC, My Company
2010 Speaking Engagements
Video Interviews
DZone Articles
Four software development guidelines
Posted By : Dan Wilson
October 25, 2007 10:36 AM
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!
There are no comments for this entry.
Add Comment
Subscribe to Comments
5 & 7 overlap with your point 4.
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.
This reminds me of a former life as manager of a C++ development team where I became (in)famous for saying "OK, take a step back... what are you really trying to achieve?". Programmers have a general tendency to get focused on a solution and often become determined to make it work when it might just simply be the wrong approach. I feel your pain and I'm glad you realized the problem - and blogged about it!
That is one of the biggest lessons I have learned as manager. Either I have looked at a problem form the wrong angle or made the same mistake and noticed it or realised it when it was too late.
Wow What a Great Article on Four Software Development Guidelines it's really very useful information for the Software Developer as well as Connected people of Software Development thanks for providing us that important ionformation
Thanks
MAG Studios
mag-corp.com
Hi i thinks its one of the interesting episode. I have learned this. Either I have looked at a problem form the wrong angle or made the same mistake and noticed it or realised it when it was too late. thanks
Suscribe
Follow Us
Contact
This is a trap I'm sure every developer has fallen into... The important thing is to catch yourself before you get too involved. Is it time to step back and re-evaluate? Walk down the hall and ask someone for a second opinion?
I'm all about KISS. The rock band rules too.