Friday, January 09, 2009

Sam Halperin (a good friend of mine), just posted some interesting thoughts about software development, and I thought I'd reply with my thoughts here.

"Someone once said that the number of bugs in any software system is constant."

That is certainly true, but only because the number of bugs in a non-trivial system is equal to N+1, where N=the number of bugs that you know about. So if you start with N+1 and then subtract 1 from N, the value of N has gone down by 1. But, you still have N+1 bugs in the system!

It's important to remember that this is for non-trivial systems, and is more of a macro perspective than that taken at the lower levels of the software development process. It is absolutely possible to design a function that is bug-free (assuming that the underlying compiler, machine language and hardware that it will utilize do not have any bugs that will directly effect its operation), it just can't have many function points in it.

"When do you throw out a system entirely and start from scratch with a new version?"

Sam asks a good question here and, when something like this comes up, I always like to validate my thinking by finding out what better minds than mine have to say on the topic. In an interview by Bill Venners, Martin Fowler answers a question just like the one Sam asks:

Bill Venners: In Refactoring, you list several problems with refactoring, including situations when you shouldn't refactor. How do you decide when you should start from scratch and throw away existing code versus refactor it?

Martin Fowler: The answer is: I don't really know. If you have no tests and cruddy code, then you should probably throw it away and start again because you'll have to do all the testing, as opposed to if you have cruddy code with many tests. If the code is riddled with bugs, then behavior-preserving transformations will of course preserve the bugs, so that might be an argument against refactoring. I think the answer to your question also changes as your comfort level with refactoring increases. As you become more confident with refactoring, you'll want to refactor something that you'd otherwise want to rewrite because you're more skilled at refactoring.

Martin has an interesting perspective here, and one that I actually agree with... again, as long as we are talking about non-trivial systems. Besides the engineering aspects of executing a good refactoring program within an organization, there is often a financial benefit of not always starting over. However, the comment that Sam makes about the difficulty of taking over a code-base that might not be designed or implemented in a way that is conducive to understanding and refactoring (think about all that spaghetti code that you have run into in life), is a major concern as well. In order to be in a position where it actually DOES make sense to use refactoring instead of rebuilding, you have to start on solid footing.

One other area to consider in this discussion revolves around technology shifts, and their impact on a "legacy" code base. Every couple of years (it seems to be 3 to 4 years), enough of a shift in the technology landscape has occurred, either as a jump or as accumulated organic changes, that you have to seriously consider the potential value of migration to a new platform or approach. This obviously costs money to do, but the risk is that the further behind you get the more costly catching up can be.

This leads me to a topic that I've been thinking about recently, the buy vs. build decision process that organizations are constantly having to answer for themselves. I'm working through my thoughts on that right now, and will be sharing it some time soon.

Labels: methodology, software development