My last post discussed the importance of source code and how it should be treated as an asset. The assumption that I made was that the software would be long-lived, with a continuing need to enhance it over a long period of time. In real life, we’re faced with uncertainty. We don’t know what will be accepted by the market and what won’t. The only thing that is certain is that we won’t know unless we try.
This means that a fair number of software applications die soon after initial development. An initial release of a product is meant to test the waters; and in the face of non-acceptance, it vanishes. Other applications don’t reach the levels of anticipated or desired use to warrant a high degree of care and feeding. They are maintained, but are more like zombie applications – the living dead.
Source code is an asset, but there is a cost to building and delivering software that is well-designed. Should you incur that cost when all that you are doing is building a trial balloon? There’s also another wrinkle that surfaces involving people. A college instructor of mine used an analogy related to firemen to describe the dynamics involved:
“There are two types of firemen: drivers and buckboard riders. The drivers are the ones racing to the fire to get the people out and beating back the fire. The others are buckboard riders, the guys who stand on the buckboard and ride with the fire truck. They set up the hoses and back up the guys running into the burning house. And they finish dousing the flames once people are out and the fire is brought under control.
“Programmers are like that. There are those who are always trying new things, who have that exciting new idea that they can’t wait to get implemented. They’re going to be pushing the envelope, but they are going to make a mess. There are other programmers who are more deliberate, who want to keep things orderly. You need them to come behind the other programmers to clean up after them.”
I’ve personally witnessed this scenario play out a number of times. There are those programmers who have an entrepreneurial spirit about them, who are focused on the market need and are willing to experiment with different approaches to meet that need. And they keep up with the latest technology, looking to leverage the latest breakthrough in whatever they are working on.
Unfortunately, the burning desire for speed with these types doesn’t typically translate into well-designed code (although on rare occasions it does happen). More often than not, features start getting stuffed into the product almost experimentally. And while the end result – from the customer’s standpoint – is a truly innovative and useful product, you might have a mess on your hands from a source code standpoint.
If the product isn’t accepted, it will either vanish enter that zombie-like state where the state of the source code isn’t a concern. No harm, no foul. However, if the market begins to adopt the product, you risk being on that roller coaster where things are great early on, but you will sink under the weight of poorly-designed code at the wrong time: when the software is enjoying extraordinary success.
There are two tactics that can be used:
Treat the initial product as a prototype that should be discarded. This is particularly useful if you have entrepreneurial programmers who are more focused on the business need and less on what they are cramming into the source code. Let other, more disciplined programmers build out the “real” product. The entrepreneurs won’t mind, they will want to move on to the next big thing.
Build out the minimum number of features to test the market. Make those features well-designed and deliver that small set quickly. You will avoid incurring unnecessary expenses in building out a product that is too broad (keeping in mind that a majority of features are never or hardly used in many software products). This tactic is useful when business types are determining the feature set more so than the programmers. They aren’t inclined to view software as a prototype that needs to be rebuilt. Business people generally perceive this as reinvesting in work that they’ve already paid for.