Survive and thrive. How to build a successful digital product.

Herein lies some home truths that are particular to our industry. Home truths that many find difficult to fathom, and you may find challenging. They have been hard earned by us, through years of endeavour and curiosity. But to you my friends they are given willingly.

You’re welcome.

There are no economies of scale

The more quantity of something you buy the cheaper per unit you expect to pay right? This commonly held belief has led us to expect economies of scale in pretty much everything around us. By extension, the bigger the software, the cheaper each ‘unit’ is going to cost. It’s a fair assumption, but one which couldn’t be further from the truth. Expect instead the truth in software development runs counter to the idea that the more you invest the cheaper each unit will cost because:

• The more lines of code in the software, the more effort is involved in maintaining it. In other words, just treading water becomes more expensive.
• The more lines of code in the software, the harder it is to change, the harder it is to debug and the longer it takes for someone to understand.
• The number of different communication channels increases rapidly with the number of people on a team due to ‘combinatorial explosion’. This contributes to a phenomenon where a small team of say 5 can outperform a large team of 50 (yes, it happens).

You cannot test quality into a software product

Testing software, that’s something that’s done at the end of your development work right? To make sure there are no defects before it’s released? Have you also heard the idiom ‘close the stable door after the horse has bolted’? Well, that’s what this is right here. Because once your software has defects developed into it, and make no mistake, those defects are developed into it, it’s already too late, you already have rework on your hands and you already have a development process with little or no strategy for preventing defects in the first place.

We could start by thinking of quality control as an activity for the entire organisation, not something that gets appended at the end of development.

In light of this, what might we do to reframe the discussion to one of defect prevention as opposed to detection? We could start by thinking of quality control as an activity for the entire organisation, not something that gets appended at the end of development. We could consider standardising our approaches, including the way we communicate requirements, and we could continually improve our standards each time a quality issue occurs, with the aim of working towards preventing all quality issues in the first place.

Choose simplicity before generality

A lot of people think the way to ‘future proof’ software or to write software ‘efficiently’ is to make it general purpose. That’s to say to extend the functionality beyond the specific current known needs to something more generic that may meet future needs. Don’t be fooled. Firstly, any predictions of future uses of the software beyond what specific needs are known is just guess work. The more guesswork you make, the more speculative your software becomes and the more likely it will end up satisfying no purpose. The result? Lots and lots of software, little or no value. Secondly, any ‘efficiency’ savings you think are being made by making something general purpose are dwarfed by the overhead involved in producing and maintaining something general purpose:

So what’s the answer? Ground your decisions around specific needs, solve these needs as simply as you can and build your software in such a way so it can be changed as easily as possible.

Being busy will make you less effective

We’re working longer and longer hours and yet our productivity is at all time lows. We’re so busy being busy we have little time to learn anything new. We’re unable to adapt to changing circumstances because we just don’t have the time to do anything other than maintain the status quo. Our desire to maximise ‘efficiency’ by keeping people busy is causing us to thrash the engine whilst paradoxically remaining in neutral.

Our desire to maximise ‘efficiency’ by keeping people busy is causing us to thrash the engine whilst paradoxically remaining in neutral.

It’s time for teams to stop thrashing the engine. They need slack in the day to spend more time on the things that will help move the organisation forward such as learning, thinking and building relationships.

Adding people to an already late project will make a project later

Let’s get something straight: we do not work in a factory or on a production line and we do not spend all day mindlessly ‘copying and pasting code’ that someone else has already written. The human beings involved in said work are not ‘plug and play resources’. By extension, what you’ll find is that if a project is already late, adding more people will almost certainly make it later. This is known as Brooks Law and is explained by several factors:

• Ramp up time: it takes time for any new team member to understand existing code, processes, tools, environment and practices
• Education: it takes time for existing team members to help new team members understand existing code, processes, tools, environment and practices.
• Communication overheads: due to a phenomenon known as ‘combinatorial explosion’, the number of different communication channels increases rapidly with the number of people.

Most measurements are harmful

Outputs such as lines of code, pull requests, velocity, features developed are EASY to measure. But the same can be said for the calories in a Big Mac Meal. That doesn’t make a Big Mac healthy. And likewise, a lot of measurements in software bear no correlation to positive outcomes. For example: if you measure lines of code, what do you think you will get more of? But what is it that costs your organisation to write and to maintain? What is it that slows you ability to adapt your business to changing circumstances? Hint: it’s more code.

What if a particular business outcome could be delivered by more thinking, more talking, more collaboration and less code?

So let’s consider this: what if a particular business outcome could be delivered by more thinking, more talking, more collaboration and less code? What if in fact it could be delivered with no code? And then ask yourself, is this ever likely to happen in an organisation where lines of code is a way of measuring performance?

Go slow to go fast

Throw together a team of the smartest, the most specialist individuals and so long as they work hard you’ve got a winning team right? Wrong. Google demonstrated with Project Aristotle that in teams exhibiting softer skills such as ‘ equality, generosity, curiosity toward the ideas of your teammates, empathy and emotional intelligence’ were far more likely to come up with the productive ideas. Teams where individuals ‘ don’t always have to be the smartest people in the room ‘ tend to outperform the so called ‘smartest’.

And what do these soft skills require? They all require time to nurture and develop. There’s no shortcut.

Work that’s been done but not released is a liability not an asset

Traditional cost accounting places inventory as a balance sheet asset. In software terms, inventory can include ‘work in progress’ or work that’s been ‘done’ but not released. Feels right that this hard work is an asset doesn’t it? Well it isn’t. And your accountant is wrong too. Quite simply, you’ve got a liability on your hands and here’s why:

• Maintenance effort diverts resources and costs money: any work that’s not released needs maintaining just like production code because software suffers from entropy; it gradually declines into disorder over time.
• You’re not learning anything: any further work risks building assumptions on top of assumptions which will likely result in more and more rework.
• Customers’ needs change over time: If you can’t keep up with what your customers need you’re in trouble.
• Anything that could be deriving value but isn’t has lost revenue associated with it: for example: something that could derive revenue of £10,000 per week that waits for 4 weeks before being released has cost the business £40,000

Reduce batch sizes, focus on flow, deploy frequently and reduce the number of things you’re working on at the same time.

So what’s the answer? Keep batches small, focus on flow, don’t use long lived feature branches, deploy frequently, reduce the number of things you’re working on at the same time. In other words, keep inventory low.

If you have an idea for an innovative digital product or service, why not partner with a company which nurtures better collaboration, better results, and better alignment on both sides? Let’s chat together@wemakewaves.digital.

Originally published at https://wemakewaves.digital.