Ninja rockstar bottlenecks

If you read or even skimmed my article Create your own dysfunctional single-page app in five easy steps that I published yesterday, you’ll see that I promised a follow-up looking at ways of getting out a bad single-page app situation. Now I just have to write the thing…

I thought it would be fun and useful to do a bit of writing in public, so I’ll be exploring some ideas over the next few daily emails.

The article identifies five mistakes that teams can easily make when building big JavaScript-heavy web apps. Mistake one is ‘under-estimate long-term development and maintenance costs’.

It would be naïve to think that this problem is unique to JS apps. It’s a problem with developing software products in general. We all know how terrible we are at estimating the cost and time required to deliver software.

But the problem is compounded for SPAs by the lack of experience and understanding that many teams have in knowing what’s required to deliver and maintain a high-quality product.

Many teams aren’t even aware of what they’re spending to keep an existing application going, or how much it costs to make even the smallest of enhancements. And it’s hard to compare that to what the cost would be for the same feature within a system that is more amenable to changes and improvements.

As a result, many teams just quietly ignore these hidden costs for long periods of time. This can have a chronic effect on sustainability of a product.

So the first step here is to find ways to uncover these costs. This is not necessarily about coming up with a concrete financial amount. Though financial estimates may be needed in order to make a business case for strategic changes, within a product team it’s probably not necessary.

Instead, it’s far better to understand where there is waste in the current flow of value to end users. This is lean-consultant-speak for discovering where work gets stuck. I’ve previously written about using value stream mapping and lead time ladders in particular to uncover the waste in your product development flow.

It may surprise you how much time feature work spends in queues – i.e. waiting to be worked on – rather than in active development. Other things to look out for is work that is frequently blocked because it requires a specific person to work on it who is not immediately available.

These are people problems, but can also be closely related to how the code base is structured. For example - a highly-coupled codebase with poor test coverage and no documentation is much more prone to bottlenecks caused by silo’d knowledge. Having a unicorn rockstar ninja fullstack developer on your team that everyone depends on and that all work flows through is not a good thing. It’s a sign that you have a bottleneck that you need to address.

I highly recommend Clarke Ching’s short (and cheap!) book The Bottleneck Rules to help you see and address bottlenecks. Or if you prefer fiction, try The Phoenix Project, in which one of the main characters is a big bottleneck.

Next time we’ll look at how we can free up some time from the relentless parade of feature development to work on incremental improvements…

In the meantime, reply and tell me what the biggest bottleneck is in your team. I promise I won’t tell anyone if it’s you ;-)

All the best,

– Jim