Blog An exploration of the art and
craft of software development

The Simplest Thing That Works

Posted by Marty Haught on Monday, March 30, 2009

This phrase, or the original ‘The simplest thing that could possibly work’, comes from Extreme Programming and is something that I’ve worked with for the last five years. In essence it is a goal to avoid unneeded complexity and strive for simplicity. But I don’t want to focus this post on the usual technical aspect of this topic. There are many more eloquent posts on the subjects by those that championed this principle years ago.

Instead I want to mention how this thought has come up in the recent months. The main application of this principle is in business direction and building an application from scratch. It is very easy to make a long list of features your new application needs to be successful or usable. This is a trap you want to avoid. Yes, eventually it would be nice if you had all 20 of those features. However, do you need all 20 before you have a usable product?

The first instance of this was in my role-playing game that I’m slowly working on. Since I’m working on it in my free time and I’m solo, I really can’t afford to finish dozens of features. Instead I really sat down and thought about what’s the minimum set of features my game needs before I can start playtesting it. I challenge myself to how little code could I write to launch an alpha between me and my closest friends. Though it has been slow going I can say that I’m pretty close to having this and using this approach has helped me defer many features that aren’t needed in the alpha. What’s cooler about this is that I may discover that some of the features don’t add value to the game and I won’t need them as I originally thought.

I’ve been on two other projects recently where this approach became the focus. It’s almost like I’m spending more time widdling down ideas into their essence than thinking about implementation details of all these requests. That wasn’t always the case. I loved delving into difficult domain problems and come up with complex solutions that could handle anything. It turned out that when I went in that direction I wasted time on issues that never really panned out. But the client was directing us that way and they were providing a nearly endless bucket of hours to do so.

The most recent instance was this new project that I’m bidding on. Again, the client wants something as soon as possible and is open to the idea of a super bare feature set to just start playing with it. I have been working hard on looking at every single feature as well as the fullest of such features to see how fast I can deliver the first build to him. Matter of fact, I’m wondering where this approach isn’t the best way in all applications. So far I haven’t found a single case since I started pondering on it.

Another interesting twist on this idea is when it comes to launching your own applications. Let’s say you have a solution to some problem that ails you. Even though one or two features might solve the immediate problem you start thinking about how you can make your idea more appealing and put it on its way to conquer the world. Worst yet when you start worrying about all the features you’ll need to sell it off to Google for millions of dollars you become paralyzed because it’s now overwhelming. Why not try the simplest thing that will work? Build the one or two features and launch it. Is that good enough for you? It might just be good enough for others. You can always add more features later on as you want them. Given the ease of putting up new web applications there are few excuses left not to try.

blog comments powered by Disqus