Market Uncertainties and Source Code…

February 25, 2011

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.


I believe it's really worth your while to invest effort in trying to figure out what problem you need to solve before digging in. It now seems clear to me that conceptual work (UX design! domain knowledge) is of utmost importance.

I just read "The Inmates Are Running the Asylum" by Alan Cooper recently. It made me realize this.

There are a lot of useful insights in the book. Most important to me seem to be 1. Design for the mediocre (not beginners nor experts) 2. Design for actual people (use personas and such tools) 3. Don't let UX design happen implicitly (programmer driven approach :) )

I guess a good product design process could go something like this 1. Market research (find actual users with actual goals) 2. UX design (figure out "vocabulary" and overall workflow to allow the users to reach their goals easily) 3. Testing (acceptance tests and such derived based on UX work) 4. Implementation (arch work, algos and such)

This seems very humane way to develop and effectively lets programmers do what they do the best. I believe it's cheaper to work this way as well since you get a clearer idea of what you are trying to solve earlier on and have more freedom to experiment on conceptual level.

The problem with implementation driven approaches is that they tend to "ossify" design. Once something is implemented it gains certain kind of momentum. Since it costs money and time to implement something it might not make sense to throw away work. At least there are significant psychological factors working against this kind of thinking.

February 25, 2011 at 10:45 AM

Post a Comment