Building a Software Product? Quick Fixes Will Burn You Down the Road
May 16th, 2006 by Matt InglotTo my regular readers: this is a little off what I normally write about, but it’s my blog and I reserve that right!
Software is a strange creature because it can never be perfect. In fact part of the trick to successfully deploying a great program is applying the 80/20 rule (or whatever ratio applies to you) to bug fixes in order to not waste prepostreous amounts of time and money fixing that last little glitch. Simultaneously a buggy program quickly loses its usefulness, so there must be balance between being perfection and being lousy. I’m here to offer one very important distinction to aid you in restoring this balance.
If You Are Going to Fix It, Do It Right the First Time
It’s very tempting to hack solutions in when you need something extra in your software, be it a traditional desktop application or a web application. Doing it right can often be costly in time and money, while a hack can take five minutes and save the budget. We can always redo it when the resources are available right? Well time moves on, the hack is never fixed, and slowly more and more of the code and users begin to depend on the hack. The amount of fixing that now needs to be done begins to multiply and pretty soon your little lifesaver is eroding the entirety of your application.
I’ve fallen victim to this more times than I can count. I recently spent all weekend fixing design problem in user management code that I wrote three years ago. A lack of foresight has required almost completely gutting the existing code and corresponding access routines, leaving me with gobs of dependent code that now needs to be fixed. The past can come back to haunt you, and when it does the cure is now much worst than it was in the past.
It Comes Back Down to Design
Whenever introducing a new feature or beginning an application, careful attention must be paid to the design. Ultimately you want something that will not only work well when its released, but will also be able to have the needs of the future easily integrated into it. I’ve been rewarded heavily for my foresight when I began a site framework years ago, because that base code, including the very first file that was ever written for it, is alive today and thanks to its modularity and high expandability it doesn’t feel dated.
Here are some general rules to check for to make sure the code that you are about to write is going to be a very sour gift for your future self:
- Flexibility: Don’t write a module that can only add a specific column of data when it’s only slightly harder to make it work for any column. Providing a reasonable amount of generalization encourages re-use which in turn lowers the amount of bugs that can creep in (as you aren’t duplicating the same functionality over and over).
- Modularity: If you aren’t writing a highly modular application that can easily have functionality added and decoupled then you are putting yourself at a tremendous disadvantage against nimble competitors like Google who completely redefine expected behavior and functionality overnight (see why GMail is destroying Hotmail). I like code that behaves like LEGO blocks.
- Sanity: My all-encompassing description for code that makes sense. This means avoiding strange solutions for problems (typical result of micro-optimization or laziness) and writing intuitive self-descriptive code. You should be able to look at the code years from now and have it make sense.
What you do in the present should be for the purpose of building up your future, not leaving future self a mess to clean up. This applies to software!
Got something to say? Leave a response to this post.
del.icio.us
digg
Reddit
Get the latest updates by subscribing to the feed.
Semi-Related Posts
