The Best Features Are The Ones You Don’t Ship
This is an extract from my book "simplicity." The layout has been simplified to work with substack.
I can’t help it. Just like the lab rat pushing the button to get the next food pellet, I love delivering features; creating and delivering something new. In the past, I was known for delivering features the customer didn’t even know they wanted. That’s a superhero play.
It’s also ridiculously stupid.
Every feature we add to our software represents a future liability, because all that code will need to be supported, maintained, extended, and understood by new developers.
Does that stop everyone adding feature after feature? No.
Should it?
Yes, sometimes.
Need Driven Development
There’s a basic rule for keeping software simple: don’t write code unless someone needs the functionality it provides. And “wouldn’t it be cool if…” and “it’d be really easy to add…” don’t count as need.
Obviously, need depends on your context. If your company is creating a mass-market product, then the marketing folks will likely be keeping an eye on competitors and creating feature requests to keep up and surpass them. That’s genuine need.
But if you’re creating software for a single client or internal use, then the concept of need becomes more interesting. It can also be tainted by politics.
I’ve spoken to managers who have to budget for software development. Every year, they prepare a report saying what they want to build, how much it will cost, and what value it will produce. They’ll receive back an approval to spend some amount, normally lower than their request. So what do they do? They add all the features they think they might need to the project before they submit it. This both bumps up the price and also acts as a form of insurance; they don’t want to ask for a baseline project this year only to get turned down for the extensions they need next year. This applies to both internal and external clients.
But we can be more agile than that. Back when I was delivering software to paying customers, I’d flip the equation around. Rather than talking about need, I’d ask the customer where they’d extract value from the project, and what their priorities were for doing so.
Then the team and I would go away and assign a level of effort to delivering these values. This is purely internal to the team: we just needed a sense of how big the task was. The result of the guess would be as simple as “easy,” “medium,” “difficult,” and “unknown.”
We’d take these rough estimates and compare them to the value they’d deliver. Assuming the dependencies would allow it, we could then work out which features we could deliver early that would also give the customer a decent amount of business value.
Then we’d go back to the customer and say something like:
We’ve been looking at your requirements, and we think we can give you some options. This first is a conventional project, where we deliver the software to you at the end.
With the second option, we’ll deliver the software incrementally, feature by feature. We looked through your list of values, and combined them with our project planning, and we feel that we can deliver feature X well before the final project is complete. You should be able to start using it then, getting business value early. We can talk nearer the time about subsequent deliveries, but right now we think we might look at features Y and Z next.
This gives the customer two big wins. First, they can start earning some value from the software earlier; value now is always better than the same value later. Second, your customer gets to experience using this first deliverable. In my experience, when the customer first uses a partial delivery, they suddenly realize things about the system that weren’t apparent when it was just some words in a document. They’ll be able to come back to you with ideas and suggestions for next steps that might be radically different from their original request. In fact, a while back I had a customer who took the first two of five feature deliveries and then said the system did just what they needed; the extra three features were there for insurance, and they weren’t required.
It also gives you some massive wins. First, you get feedback a lot earlier than you would. Ideally you’ll be talking with the customer every week, but often that just doesn’t happen. But you’ll definitely get their attention when you deliver something. Second, you start to build a trusting relationship with them. When the project started they were taking a risk on you. When you deliver something, even if it’s not the complete project, they’ll start feeling a lot more comfortable, and you’ll find that you’ll get more open and useful interactions with them. Finally, this approach catches potential problems early: if you have a misunderstanding that would propagate throughout the code, finding out early stops a whole lot of rework later.
Simplicity
You can’t ship software that does nothing. But you can work to reduce the number of features, delivering only what’s needed, free from unnecessary embellishments or complications, and delivering it earlier. Features can always be added later.
Your turn
Look back at some projects you’ve delivered. What percentage of the code in each gets used on a daily basis? What percentage would you guess never gets used?
This was an extract from my new book, simplicity, now in beta at pragprog.com.
