Banish Ghosts in Incremental Development

Developers love making new things. Despite our best intentions we have a tendency for gold-plating, leading to bad unnecessary solutions, and we like to make frameworks, despite often not having enough data on which to base the design of that framework.

This, on the whole, is bad for incremental development.

That said, if you choose your frameworks well, then you get a lot of features for free. A living breathing application straight out of the box: what’s not to like?

Early Increments Should Be Small

When starting a project, there are a few goals:

  • Show immediate progress – buy trust
  • Start to refine where the feature roadmap is going with user/expert feedback
  • Open up the technical real estate to multiple developers
  • Avoid technical debt

Each of these is critical (it’s not an exhaustive list, I’m sure) and there are some conflicts.

You could show immediate progress by turning on all the features of a framework, creating an app which looks amazing… but doesn’t really work.

You could sketch out a wide framework with loads of room for development, but is undemoable.

You could cludge together some user features, but create a mess of code.

You could take a softly softly approach to development, but only have room for a couple of developers in a tiny codebase.

Stay on Target

The essential trick is to keep focused on what’s needed to make the early version. There are requirements across the technical and functional stack. There should be:

  • Tests
  • Builds
  • Deployments
  • Demoable features
  • … and of course the code

This means that you have to ensure that any features that are built are the simplest version of a thing that can be demoed.

Ghosts May Haunt You

Let’s revisit that last aim:

Build the simplest version of a thing that can be demoed.

Put that on a mug, or poster!

Frequently, our frameworks offer us gold-plating. They provide us additional options out of the box. Multi-selects, or five ways to input into the same box. They assume you’ll need things like pagination or sorting. This means that early wireframes of our UI can contain features that we’re not planning to use yet. Or it means that our UI has flexibility that would require a bit more maturing before it’s ready.

This is similarly true of back end technologies we might employ. They can do loads of things we’re not planning to harness yet.

This is where the ghosts come in. They’re implied features that we haven’t the time, at the moment, to flesh out properly. Or worse than that, they allow for edge cases that we REALLY haven’t thought through.

Banish the Ghosts

While it’s tempting to show progress early on with the potential of features we can nearly have, and while many of those features come by default, it’s important to treat even week 1 features of our product as though they’re release candidates.

The product should be the smallest production-ready version it can be.

A half-formed feature which doesn’t work in practice is a commitment to complete it or rip it out. A small fully-working feature is a release candidate.

While showing off about the potential can impress stakeholders, it doesn’t gain as much trust as demonstrating a complete, working, release candidate which is ready to go. If the stakeholder says “So, it can do X then?” and you have to reply “Well, not really”, it’s a negative.

The illusion of progress confuses discussion and can even make the stakeholder think you’re building on your own priorities, rather than those of the project. “Why are you building X I didn’t ask for, and not yet building Y that I want more of?”

Exorcise The Stubs

There will always be examples where it’s easier and more technically expedient to just keep some default feature and make it work. However the baseline should be that we turn off everything we don’t need, and build as little as we need.

In the short term, this will appear to require us, occasionally, to put in more effort to have slightly fewer features.

However, it provides:

  • Reliability – the whole “product” actually works
  • Clarity – there are no implied surprises
  • Focus – if the product owner really wants that feature, they’ll soon ask for the version of it they want

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s