Understanding what really matters for timely software delivery
I had a discussion last year with a CIO at a global bank who was contemplating how best to tackle developer productivity. His thought was to measure code commits. I thought this to be a strange approach, so I explored his reasoning asking him “Five Whys”:
Why do you feel measuring code commits will be useful? He wanted to know how many developers they had actively writing code.
Why do you need to know the number of developers actively coding? He replied that the team is many thousands globally and it is not clear who is writing code regularly.
Why would knowing the number of developers actively coding be a useful view into productivity? He said that he needed to understand the available people power in the organization.
Why would people power be helpful in your understanding productivity? He responded that there was a large amount of backlog in engineering and he thinks they are short staffed.
I paused for a few moments to formulate my thoughts before posing my final “Why”.
Why do you think nine women can’t have a baby any faster than one woman can?
Okay, that was not the question I asked, but it was on my mind as we were deep into discussion about engineering metrics and productivity. With an engineering organization with hundreds to thousands of developers distributed across many locations and time zones, getting an accurate pulse on what people are doing can be maddeningly difficult.
You may recognize my quip from above as an example of Brooks’ Law. In 1975, Fred Brooks wrote one of the most influential books in software engineering, The Mythical Man-Month. He observed for software projects, adding people delays delivery.
On the surface, this sounds counter-intuitive. Instead of helping reduce effort, each person you add to a project does the inverse. Our expectation would be adding people helps. How common is it to hear of the lack of staff as a reason for the growing backlog of work and the inability to act on new requests from the business?
More work should lead to more people in many circumstances. Startups cannot scale without rapidly hiring. Product teams often need new skills as new functionality is added. IT teams transitioning to new architectures and platforms need to bring on experts to do the work and educate existing staff.
As complexity and scale grows, so does the need to for more specialization. The planners and generalists are less vital once an organization is in execution mode. This makes sense since our limited understanding of the implications and assumptions made early only become clear once work is being done. Or in other words, we only know what we know once we are in the thick of things.
When I started my career as a software engineer, I experienced several painful examples of early choices leading to a different reality. I often started my projects mapping out the database schema, then creating the business logic and the UI afterwards. For a sales platform I was building, I assumed that a person only belonged to one organization. Then the VP of Sales asked me one day why he couldn’t add multiple companies to a person.
Now I understand the need to build flexibility into data models (or perhaps go NoSQL). To track current and former employers, add associations, or track consulting assignments, having a many-to-many relationship between people and organizations is the right choice. In a twist of irony, I later joined a well-known company called Siebel Systems that made the same data model mistake, but at a vastly greater scale and cost.
This is the subtlety of what Brooks said that is often missed. His intuition was that adding people at the later stages of a project is what slows down progress. This is because new people need to be onboarded, which takes several weeks. They do not have an internal network to know who to ask for help, nor have they gained institutional knowledge. When they do ask questions, they interrupt others, which impacts the productivity of members on the team. The result is greater communications overhead.
How much does this impact productivity? One study showed that it took up to 23 minutes to return to one’s flow after an interruption. If there are multiple interruptions as is common, the productivity hits can begin to have a significant effect on delivery times.
These are issues that Brooks observed during later stages of a project. Early on when strategy and planning matter more, adding people along the way makes sense. As the plan solidifies, the needs are more well-defined. Therefore the question is not whether adding more people is inherently bad. Rather we should be asking who are we adding and why?
The answer to “who to add” often runs into a misconception of how developers write software. Non-technical managers assume the creation of software is like an assembly line. If you want more output, just add more assembly lines and workers. Code is like widgets and the workers on the assembly line are interchangeable.
Modern software development has more in common with Jack Kerouac or Jackson Pollack than the Henry Ford view of work. There is creativity and problem solving involved that makes our standard measures of predictability ineffective. This is why measuring code commits or lines of code produced tells us nothing about productivity.
The other aspect of coding is that the work of a developer exhibits atomicity. The work is one problem and one artifact which equals one unit of work. This is analogous to the woman and her pregnancy, one person alone and only one person can carry through the work from start to finish.
When thinking about the question of “who to add” then, it is important to emphasize adding more developers is meaningless without context. If there are new features or technologies involved, then adding resources with the specific domain skills to execute on this work is reasonable, such as adding new API endpoints or moving code into microservices.
The why behind adding resources however is the bigger question. During Brooks’ time, the predominant project methodology was waterfall. Now enterprises are shifting from projects to products and adopting Agile to release products and new features in shorter cycles. This was true of the bank I spoke of earlier. Yet despite “two-pizza teams” and other Agile dogma, big projects, long release cycles, large teams still exist.
Perhaps Brooks’ Law then is still relevant. It matters for organizations that view coding as widget making, implement Agile in name only, take months to deploy features, and believe developers are fungible resources that are easily interchanged. Those organizations will always be singing the late project resourcing blues.
For leading organizations however, they ship features continuously. Teams have the right talent and are sized appropriately to deploy code quickly. Unknowns are addressed earlier on and have less impact and dependencies. Brooks’ Law is simply not a thing.
How have you addressed the issues of project delays and what caused the delays in the first place? What did you implement to help speed up project delivery?
Episode #7 — Four key metrics for cloud migration with Shaun Norris
The Heretechs
Episode #7 - Four key metrics for organizations to migrate to modern robust cloud architectures Co-hosts Justin…heretechs.io
Revisiting past episodes before our next season, this one is with Shaun Norris of VMWare Tanzu to discuss how to measure cloud migration success.
Season Two is coming up with a mix of guests at both tech startups and global enterprises from South Africa, New Zealand, Ireland, US and elsewhere. If you want to be on the podcast and have thoughts on the state of IT and Engineering, let’s chat!
Check out past Heretechs podcast episodes on Apple Podcasts, Google Podcast, or wherever you listen to your favorite podcasts. Please like and subscribe 😁
We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.