What slows development teams

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law. – Douglas Hofstadter

Developers and their managers both want scope and delivery time to match, but despite working for a common goal they rarely do. Often the gap is so large that deadlines are missed, products become irrelevant, and teams can face burn out.

There are three major schools of thought on why Hofstadter’s Law exists:

• Software is Art
• Software vs. Entropy
• Productivity Declines

Software is art. This school of thought describes software development as a new field (we don’t have centuries behind us) that is inherently prone to underestimating challenges and describing exactly how long something will take. There are debatable claims made here, however, they correctly identify the industry isn’t doing a great job at measuring work, which is a fundamental requirement to measure success (e.g. Software is Art, We’re Gardens, Not Engineers).

Software vs. Entropy. This school of thought describes that more moving parts in software makes it harder to grow, maintain, reason about, on-board new developers, and ship quickly (e.g. Mythical Man-Month, Working software is only half the job).

Productivity Declines. This describes software slowing down as a result of talent, process and environment. You may have great developers with processes that don’t fit your needs, developers who don’t meet your needs, or simply not giving developers the kind of space to dedicate focus to their mentally challenging work (e.g. 10x developers, Context-Switching, Small Batches, Flow).

Who’s right?

Really, all three have an element of truth to them.

As a quick and dirty way to gauge the problem, we conducted an informal survey of 50 people who self-identify as professional programmers and managers (those who write code or manage ‘every day’). While the sample size is small, this nonetheless serves as a signpost for the types of challenges software professionals find themselves running into every day.

The goal wasn’t to diagnose or find the reason, but rather understand perceptions and mindsets for different stakeholders and the way teams work.

Key data points were:

1. How often does software get released (bugfix, features, everything)
2. Are you a manager, developer, or both?
3. How often does one of these slow you down:

• Technical debt or underestimated challenges
• Product requirements change while work is in progress
• Business direction changes while work is in progress
• Developers are interrupted or deprived of focus

4. What can improve things?
5. What can slow things down?

What do we believe slows development teams down?

Overall, all groups had some level of issue with each category, but when aggregated by group there were notable differences in perception. Possibly even more interesting is that developers who are also managers perceive all issues as being more frequent than their peers who only fill one of these two roles.

It’s widely understood that the least important thing gets the least focus, so if we adjust for “perception” by ranking the lowest score as zero and highest as 100 we can get an idea of what is more important than the other, based on respondent type.

Here’s a look at that projection:

The headline here is that Developers and Dev Managers are not having the same conversation that Managers are. Anecdotally, we know developers are always asking for time to rewrite things. This could be due to one of two reasons:

1. A communication breakdown about technology and product
2. Faulty memory of events, or bias towards familiar tasks.

And lastly, breaking these challenges down by how often software goes out looks like this.

The key insights:

1. All groups believe interruption / lack of focus is a problem, and it outranks most problems (So why are open offices so popular?).
2. Teams that ship every month or beyond (including 3 months and yearly) see product requirements changing while work is in progress as a huge challenge, and have less problems with technical debt or underestimates than their peers.
3. Teams that ship every day have very few problems with the design team changing work, but they frequently have troubles with technology (more on this later).
4. Teams that ship every week get no love in any category 

Driving Forces

According to Managers and Developers, Agile was a huge driving force in helping teams ship faster. While there were a few who suggested it slowed their teams down, it was overwhelmingly supported. Specific shutouts went to Kanban.

Developers and developer-managers both suggested using new frameworks would improve their productivity.

A few developers were excited by new design patterns they could use to construct code, and this is a really healthy stance.

A few developing managers were excited about automating more work (especially with regards to UI testing), and performance improvements in build, test, and deploy speeds.

Restraining Forces

Some managers shared that constantly changing priorities, a failure to communicate, constant meetings, and helping others were the biggest restraints to their progress. Developer-Managers attributed slow automated processes, a bad developer culture, fire fighting, and helping others as their largest restraints.

Developers were the most vocal. Slow automated process, context switching (focus), changing priorities, too many meetings, high tech debt, overloaded sprints, adding requirements to existing sprints, lack of motivation, and unclear process were on their list of restraints.

What does this mean?

The largest obstacle seems to be a disconnect between perceptions of managers and developers.

As software moves through its life-cycle it starts with a need, gets evaluated against other priorities, scoped out and designed, developed, released, and people experience using it. Your process probably looks close enough to this that you can agree this is generally what happens, but obviously this is not perfect and universal.

There is a theory (called “The Theory of Constraints”) that actually describes two schools of thought that are used when trying to improve speed and quantity of work shipped (“throughput”).

• Cost Accounting: Focus on individual steps in a process being at full capacity at all times.
• Throughput Accounting: Focus on total throughput, individual steps don’t need to be at full capacity.

They’re radically different, and cost accounting feels so obvious and intuitive it can be a huge struggle to get your organization to abandon it. It is likely that individual managers are given incentives based on their specific group’s performance.

This may work on battle fields, but perhaps not in software development, and we know for a fact that this mindset caused many manufacturing plants to close forever. The flaw is that individual steps become competitive instead of collaborative.

When considering human biases, it is clearly more than pure coincidence that managers think the bottlenecks are more severe on the business side, and developers think it is more severe on the tech side. Both observers are attributing the problem to the thing they are most exposed to. Software isn’t the only place this happens: this is a human flaw.

Put simply: we can’t trust ourselves, at scale.

Without data, someone who can correctly identify a problem must be able to (a) correctly identify artifacts, (b) correctly remember the relevant facts, (c) recall facts perfectly, (d) has correct reasoning and interpretation, (e) was not influenced by peer suggestion, (f) was not influenced by social trends, and (g) self-image/confidence was not a factor.

One of the single largest human flaws in the planning process is called “Loss Aversion”. Put in simple terms, we all know that the average car driver feels a strong emotional pain when the price of gasoline goes increases 5%, but more of a mundane smile when it decreases 5%.

Put into software development terms, it can feel like we’re gaining something when we don’t take quality control into account because we can ship faster. Or perhaps we don’t put in the work up front designing and scoping out the project because it would take too much time from the developers writing code. NASA released a report that describes how this sort of process compounds the price paid to resolve a defect .

Put simply: we can’t trust ourselves, at scale.

Moving forward

As we move forward it is important to realize our individual perspectives are too narrow to correctly identify the issue. With a broader perspective we can identify true bottlenecks and flawed processes. If you don’t know what is wrong, you don’t know what to change. And if you can’t quantify where you are, how will you know you’ve improved?

We’re immediately biased. For instance, many developers who ship daily indicated their build process got in their way. Is it likely that these safeguards and processes slow down total business throughput, or is it likely that these processes prevent bugs in production (which are known to be orders of magnitude more expensive and slow down total throughput).

Well, without real data, you’ll never actually know.

Meaningful data cuts through office politics and subjectivity, and takes the guesswork out of success.

Software engineering is hard to measure, and the easy-to-grab metrics are either unfair or just vanity metrics. But that doesn’t mean we should just throw up our hands and give up.

As Peter Drucker famously observed, “If you can’t measure it, you can’t improve it.” Without data we are stuck in the dark with guesses and opinions.

Meaningful data can and should be used to answer questions like:

• Did our process changes make things better?
• Are we polishing a feature to death at the cost of shipping it?
• How do Wednesday all-hands meetings affect productivity?
• Which engineers made the biggest impact last month?
• How much burn went toward paying down technical debt?

Meaningful data cuts through office politics and subjectivity, and takes the guesswork out of success.

 

Brian Graham is the founder of Stata Group which helps engineering teams ship more software, faster. His experiences cover years of full-stack development, open source involvement, and community building. Follow @BrianGrahamDev on Twitter.