Sometimes movies I watch leave a lasting impression for completely unexpected reasons. Case in point – 1995 hit “Apollo 13”. The movie offered plenty of fodder for people who like to play Six Degrees of Kevin Bacon, and offered Tom Hanks in a clean 1970 NASA style haircut. A lot easier to take than the abomination on top of Robert Langdon’s head. Of course, the movie is packed with nail-biting scenes, if you bite your nails even if you know perfectly well that they are going to make it in the end. But that is not why I remember the movie.
Somewhere in the second half, the crew on the ground is trying to devise a plan of onboard system startup that is not going to suck all the juice from the remaining batteries. The battered ship’s power supply can only take up to 12 amps of current before it cries Uncle, and they have a nice analogue instrument with a needle to watch it creep up. Gary Sinise starts clean, carefully adds one by one module and before you know it, 12 amp limit is hit and the metaphorical crew is dead. Ultimately, the solution was found not in the proper startup sequence but in adding another partially shot battery useless on its own, but giving just the needed push when hooked up into the circuit as a booster.
I keep thinking of this scene looking back at software development projects I was on. It all starts new and shiny – real and metaphorical junk cleaned up, new ground broken, everything seems possible, we make crazy progress unencumbered by restrictions and customers. But soon enough, code piles up, requirements keep coming, constraints set in and before you know it, you hit the limit. It could be too many features, too much code, pages taking too long to load, UI too complex, too much customization needed – anything that marks the transition away from innocence into maturity. The problems you need to handle now are not cool, they are adult stuff.
When this limit is hit, different people react differently. Some people are forever chasing the new project high. As soon as it is gone, they start looking for another ‘new’ project in order to recreate the wonderful sense of freedom and freshness, the ‘new project smell’. Others accept the maturity process and ride it all the way. Then there is a group that actually thrives in a mature project environment – they like the structure and the boundaries it provides, engaging in a series of incremental improvements within the constraints of a mature project.
The point I am trying to argue here is that for all the allure of the early days of a project, it is the period after the metaphorical 12 amp limit that separates boys from men. The early days value your ability to dream, to conjure up new, exciting and innovative concepts, new ways of doing things, and things never done before. The next phase is all about execution, about turning that vision into reality, into something that actually delivers on the early promise. Many a startup crashed and burned on the ability to deliver, to scale when faced with the real world problems and customers. The bridge from an early prototype to a real product is the hardest one to cross. All the shortcuts and omissions you made in the rush to the prototype will come to a head and bury you if you are not careful.
For all the head swooning allure of the early days, it is the maturation of a new product that is the most exciting to me, and if you bail as soon as things become too complicated, too hard, not fun any more, you are missing out on the best part. Don Draper from Mad Men was described by a bitter girlfriend as one that ‘only likes the beginnings of things‘. Don’t be the Don Draper of software projects – see the project to the successful maturation and you will be rewarded with a payoff of a job completed, not merely started.
© Dejan Glozic, 2013