Fri 07 Aug
2009
The Critical Period of Software
Posted at 11:13 AM by Max Cameron in Project Management
The first release is a real challenge, is it not? It's the hardest to estimate, the hardest to construct, and perplexing decisions await you at every turn. To complicate matters further, when you're kicking off a multi-release project, clients want to go big right away. They're are hungry for a four course meal when you're delivering an appetizer. But it's important to help clients understand why the first release is the most precious, even though it may deliver far fewer features than subsequent releases.
The way I see it, the earlier a decision is made, the more significant and influential it is on the project as a whole. We should pay special attention to the decisions we make first, because they will not only define the outcomes of the project, but they will constrain future inputs (options to be considered when making future decisions) as well. Therefore, we should move slowly and methodically in the beginning, although the tendency is to feel urged to rush into a project because the initial momentum is so great.
From what I read, babies can recognize more than 3,000 words by the time they are 2. Some theorists argue that a person's identity is well established by the time they turn 7. It becomes exponentially harder to learn a language, play an instrument or pick up a sport after puberty begins at around age 12. In human psychology, a lot of complex things get figured out relatively early on. These ideas are generally encompassed in the Critical Period Theory.
Things that are cemented during this critical period, tend not to change. You don't just forget your first language, because it gets hard wired into your brain. That also means we tend to take these critical aspects for granted. Additionally, the fact that you learned English constrains the options you have going forward. Therefore, it's more important that you learn a language than what you end up doing with your ability to speak, read and write.
The same pattern holds true for software development. When you choose a framework or programming language to develop the application, you're constraining the options you have to work with. And we shouldn't forget that's a good thing. But the same holds true for feature development. There is no all-encompassing documentation predicting the content of an application, the decisions you make first end up being the most important ones. The constraints you establish first will shape the path the application will take on its way to maturity.
So, when you feel the need to reassure your client and maintain the trust you've worked hard to achieve, remind them that three features which lead us into a flexible and integrated future far outweigh the five that lead us into the layered control of haphazard construction.