The act of delivering software to the market is a continual learning process. My recent posts have been talking about bringing new products to market using fast, low-cost experiments to empirically learn about what really works—what customers will value and pay for.
If you have entrepreneurial types (and these can be intrepreneurs) driving your innovation, keep in mind that they are really experimenting and that they typically have a strong desire to get something in front of real customers to validate their learning. They also have a tendency to drive development teams for speed, and in response development teams start cutting corners on good design and technical practices that pay dividends later.
Other times, there is so much uncertainty about what really needs to be built that the entire development process can wind up being a giant learning exercise. Unfortunately, if that learning has been done under schedule pressure, you can still end up in the same place.
I call it the prototype in production problem.
A prototype in production is characterized by software that has been developed primarily for learning purposes, but is now in production. The good news is that you’ve proven your product’s viability. However, you have done so with early adopters who were forgiving of quality issues and have the capacity to fill in the blanks where features were missing or lacking. The early adopters evaluated your new product on its potential, and now that your product is moving into the mainstream there is a demand for those missing features and a higher level of quality.
The deceptive part of what happens next is the appearance that all things are well, that you are successfully building upon what you have. The development team shores up the quality and adds new features relatively quickly—at first. As time marches on, however, estimates to implement new features begin to increase almost exponentially. And it seems that every time a new feature is added or what seems to be a minor change is made, two or three other features break.
If you ignore these symptoms, sooner or later the development side of the house will start screaming, “We can’t maintain this code any longer! If you want to keep adding new features, we need to re-architect and re-write it!”
Look for situations that have a strong sense of urgency coupled with a high degree of learning going on. You could be building a prototype, not a long-term product. If you are, acknowledge the situation and invest in designing a robust platform to work from as early as possible.