Yes, But Not Yet

As I mentioned in Not Now, Cato, we frequently want to add all the features to the software at once. One job can lead to another, which can lead to overengineering of some things, and missing the core goal.

But it’s not necessarily overengineering that we should be worried about.

While we’re building software incrementally, we need to deliberately underbuild. Part of this to to avoid wasting time on requirements that either may change, or may turn out to be a shorter increment away from a simplistic version than first thought.

However, another major driver for not building something now is the avoidance of incomplete work.

Incomplete Work Makes it Harder to Reach Completeness

Ideally we release to production in small increments, several times a day.

However, there is probably some version of the software that, while shippable, isn’t going to be given to the customer yet. We’re before the minimal useful product, or the feature is toggled in production because it’s not really launchable outside of a small preview group.

While building we may spot something that we can roll out wide, before it gets useful and deep. The problem with that is that the surface area of incomplete stuff is now much larger. The incomplete thing is in multiple places in a form where it’s not useful.

It’s much better to double down on a small number of usable things and make them completely useful, in so far as we’ve aimed to deliver the feature, rather than open things out prematurely and increase the minimum amount of work it would take to deliver anything.

Some examples:

  • Shall we roll this view out to multiple pages? Not until it’s working perfectly on the first one.
  • Shall we add in some efficiencies of scale for batch operations? Not until we’ve got the single read/write flow working.
  • Shall I start working on that new component? Only when the current one has met its goals.

In a larger team, we often spin more plates, and have more work in progress, but the old adage still counts:

Stop starting and start finishing.

In incremental development, that also means learning how to draw a line around a smaller feature and get it to be a complete version of that feature, rather than expanding its reach before it has ever been production-worthy.

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