Could we have been persuaded by the recent AI hype that humans are no longer important in writing software?
So much of what we do in ‘software delivery’ comes across as being robotic or by-the-numbers, you’d be forgiven for thinking that this was possible.
Creating software is however not as simple as setting up some build pipelines, coding standards, ticketing systems, making architectural decisions, creating environments and dashboarding and letting everyone do their thing. But many software development companies or departments do just that. They think putting guardrails on the process and specifying ways of working written down in Wikis or enforced in tooling will ensure high-quality, well-formed software. While these processes are useful, it often feels like this is just avoiding the real problem.
So why doesn’t this in fact work?
Well, it’s simple. It’s because:
- Humans write software to solve human problems.
- Humans are imperfect at knowing what they need from the software.
- Humans make mistakes when delivering software.
- Therefore all software tends to be a compromise on features or abilities between what we want and what we actually deliver.
This means that very little software is initially fit for purpose. So most software projects will (at least initially) deliver less value than expected. This can cause tension because, despite our best efforts, we’re not delivering what we said we would or what we assumed we would.
Therefore frameworks and ways of controlling delivery become important.
However, if all of the above is true, should we ever blame a software developer for delivering the wrong thing? The developer often has less of an idea than the customer about what they want, and the customer often can’t adequately describe what they need, either with or without the help of layers of business analysts in between.
So who is to blame?
If we can’t blame the customer, the analyst, the tester or the developer – then who is to blame? Is everyone to blame? Is no-one to blame? And the answer to that is both yes and no.
We are all to blame but how do “we” improve? What can we do about this situation?
We need to close the gap between the actual requirements (which we don’t actually know) and the delivered software. This will allow us to feel if it’s closer to what we need.
By listening, collaborating, delivering a solution and processing feedback, we can iterate toward something closer to what we want. And this is essentially the basis of the Agile Movement. Agile was born out of the failure of Waterfall software development.
However, now, because of a creeping ‘processification’ of Agile, it now has a bad name. Agile is more of a business where certificates are awarded for answering nothing more than quizzes. The focus of Agile has been moved too far away from its original intention of developing better software into just another way of attempting to control software delivery.
When we can’t get control, we fall back to blame. The culture, the people, the processes, the tools, each other. But blame doesn’t get us to our goal of good software.
So how can we avoid a blame culture?
Two ways:
- A focus on facts, and not guessing how we are doing.
- Clear responsibilities for all.
Successful software development starts with good communication and clear responsibilities. Early and precise communication prevents misalignment and problems with delivery. Problems with execution and operations are eased through agreed responsibilities.
Focus on facts, not guesses.
While dashboards are generally seen as meaningless numbers, they have a crucial role as information radiators. A number on a dashboard by itself is meaningless. A number related to a bunch of other numbers over a given period can show a trend that is useful and interesting. Many numbers showing trends over time can provide good feedback on our strategies and our way of working.
Think about how you measure success and look at long-term trends rather than short-term spikes. As James Clear, author of Atomic Habits, says:
“Just because improvements aren’t visible, it doesn’t mean they’re not happening”
So perhaps, sometimes counterintuitively, creating dashboards where everyone can see what is happening with the system helps to bring a team together to highlight where there might be problems. This depends very much on the team’s openness to improvement – and openness relates very much to how much trust is felt between working parties. Trust is built when there is a no-blame culture.
So what are valuable numbers on a dashboard? Here are a few examples:
- Measure how long new features take to become part of the product (lead time).
- Benchmark and improve quality by whatever measure you think is important. This could be unti test coverage, this could be number of tests, contract testing, use of test driven development, pairing etc.
- Incident numbers, response times, time to recovery, uptimes.
- Success and failure of builds.
If you want to make a start – then you can’t go far wrong with the DORA metrics. But don’t apply metrics randomly, design them for your needs, use them when they are useful. Discard them when they a purely a measure for managers to use to assign blame.
Designing Teams to Succeed
When everyone knows what their job is, miracles occur. But a group of empowered individuals working independently can also work in opposition to each other. Defining roles is one thing, but designing and defining teams is another.
Software development is a team sport – one person cannot build a good system. Teams need to define their way of working. One practical way of doing this is to use the Team API model from the book Team Topologies. Making responsibilities and ways of working clear at the team level provides context to themselves and the rest of the organisation.
Software is Human
We often use systems to support our software delivery. These systems often become our way of working; they make us comfortable rather than encouraging improvement.
Rather than focusing on processes, focus instead on making responsibilities clear at an individual and team level and providing a way for teams to prove themselves.
Empower individuals to work independently within the scope of their team’s responsibilities. Show improvement through the careful selection and application of useful metrics. Focus on those that provide real customer value.
Good engineers get a kick out of delivering better software to end users. Let them express themselves through your choices as a leader.