When is Your Tech Project ‘Finished’?
September 23, 2013
It seems so easy. “I’ll just add one more little feature,” you think. “Nobody will ever know.” Except that the “one little feature” breaks the program, and somehow messes up the database, and you can’t seem to back out of the change. Then suddenly you’re trying to explain to a room of stone-faced executives in suits why you blew your deadline. Again.
Many developers feel, to paraphrase Leonardo da Vinci, that a program is never finished; it is merely abandoned. And there’s some truth to that. There’s always one more feature you could add, a more elegant algorithm you could use. At the same time, “the perfect is the enemy of the good,” good is good enough, and sometimes there’s no shame in being mediocre.
And while the notion of adding one more feature seems innocuous, the result can be a product that’s never finished, whether it’s intended for internal or external use. Anyone who’s ever touched up the crown molding, only to realize that the paint on the wall looks faded, and once the paint’s been redone the carpet has drips on it, and in fact none of the furniture will go with the new color, is familiar with the term “project creep.”
Business applications, which are often designed by committee — and a committee loaded with non-techies, at that – can be particularly vulnerable to this. You envision a simple application, and then sales gets an idea for how it could be used to generate leads, and marketing has an idea for social media promotion and suddenly the little project has become this giant Thing on which the future of the company depends.
An important concept to remember, which comes from the startup world, is that of “Minimum Viable Product (MVP).” According to Eric Ries, author of The Lean Startup, “the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” In other words, what is the least you can do that still provides what you need? Never mind the nice fonts or the pretty dashboard. (Of course, just picking the MVP is an art in itself.)
And despite the stories about the guy who writes something in his basement over a weekend and makes a million dollars from it, plan the application first, by talking to the stakeholders and finding out what they want and need (which may be two separate things). Make sure you have a clear idea of who your “customer” is in this context. “When [developers] fail to reach broad uptake from customers, it is often because they never spoke to prospective customers and determined whether or not the product was interesting,” Ries writes.
MVP is particularly important for mobile apps, where often a series of small, focused apps is preferable to one big app that does everything, writes Ian Fisher, CTO of the mobile app development company Taptera, in ReadWrite. Having a suite of apps lets you combine them in new and interesting ways, and also makes it easier to upgrade a single component of the workflow, he writes.
Also consider the notion of the purpose and lifespan of the application. Something that’s intended to track sales during the upcoming holiday season can be less robust than an application that controls train switching stations or aircraft landing for the next two years. And needless to say, always ensure that you leave adequate time for testing.
The notion of agile development also comes into play, because it’s predicated on developing the program in steps rather than trying to do everything at once. This means you create your one little app, get it working, and then start adding lead generation capabilities and social media hooks in future versions. (The continuous feedback loop — build, measure, learn — is also key here.)
The result may be an app that’s never “done,” but as Paul Gardner says about painting, at least it will be stopping in interesting places.