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.

Simplicity 2.0 is where we examine the intricate and transitory world of technology—through a Laserfiche lens. By keeping an eye on larger trends, we aim to make software that’s relevant to modern day workers, rather than build technology for technology’s sake.

Subscribe to Simplicity 2.0 and follow us on Twitter. If what we’re saying piques your interest, head over to where you’ll see how we apply the lessons learned on Simplicity 2.0 to our own processes, products and industry.


Robotic Process Automation, or RPA, works by teaching a software robot how to work with existing software to perform a process. Listen to learn more.

Listen Now

Related Articles

By Sharon Fisher, September 14, 2017

The year’s not even over, and it’s already setting records for cybersecurity incidents. Your accounting, human resources, and legal departments are at risk.

Read More

By Sharon Fisher, August 25, 2017

You’ve done it. You’ve automated your business processes. Now what? For a number of companies, the next step is Robotic Process Automation (RPA).

Read More

By Sharon Fisher, August 15, 2017

According to the Sapir-Whorf Hypothesis, the words you use can determine how you think about something. Here's how to make use of that in business.

Read More