Everything is a feature

There is no software maintenance

I wasted the a few years of my life following the false dichotomy between features and foundations. Everything is a feature. Specific customer use cases over everything! Foundations should emerge from features!

Please take the following points for granted as I make my argument:

  • In product development you will always be wrong. The miss may be big or small, but no one hits the market perfectly. All the market research in the world can help, but never guarantee success.
  • Tighter feedback loops mitigate the risk of wrongness. Agile development and the ephemeral nature of software let us all be wronger faster. Ship, learn, ship again.
  • Delivering an outcome generally takes the same amount of time, whether you spend time planning or you get started straight away. The sum of time spent will be the same.

When I say “everything’s a feature” my engineering colleagues usually stand up a straw-man: But what about tech debt? This will never scale! I’m not saying foundations should be ignored, but generalizations should emerge from the specific features. Pour the concrete in well-worn paths. Before customers show us there’s no way to know how the foundation should be poured. Building an abstraction for problems that don’t yet exist will probably be a waste of time.

Engineers will demand: we need to redo this better! So we build a new generalized system without real customers in an engineering ivory tower. All our assumptions are wrong and we deliver a mess of a system that had to be crammed into real-world use cases. The business and the engineers hate the experience.

Instead, let's start with a single use case, then another, then another – generalizing as the engineers deliver. This delivers value faster, better, stronger.

The thought technologies that enabled success were deliberate iteration, expecting failure/wrongness, and the trust and space to pour foundations when appropriate.