How to 10x Developer productivity — without AI
I didn’t go to university when I was 18.
Instead, I decided to have an almighty Existential Crisis and a big case of Analysis Paralysis.
So I went to university at 22, the age I was supposed to graduate. Throughout university, while all my friends were starting their lives, whizzing by, making money and doing things I was stuck in the mud, asking my dad for some beer money.
This filled my ego with a gaping hole of inadequacy, which I decided to fill up by reading books in order to accelerate my career.
When I became a manager for the first time at the ripe old age of 30, I finally raised my head above the parapet to see the chaotic world that my previous managers have been looking at all this time. I immediately noticed a seemingly chronic and nebulous inefficiency. Having sworn, in the arrogance of my youth, that I would do a better job than at least most of those managers I previously worked for, I was determined to find shape for this mighty beast of complexity and then to slay it.
Feeling lost, I did the only thing I knew. I returned to reading books and blogs, listening to podcasts and looking for inspiration.
I found myself becoming obsessed with one concept above all.
The cost of fixing a bug.
While the numbers themselves shouldn’t be taken at face value the diagram shows that the cost of finding and fixing a bug increases exponentially the further you get in your development lifecycle.
The core concept is seductively simple.
Identify problems before committing resources to them
As time went by and I started to consume more media on the topic, I saw this many headed chimera of complexity show itself take many forms, and show in many places.
To my knowledge, this was first cited by IBM in their research paper.
A white paper from Deloitte states that “most failures in software products are due to errors in the
requirements and design phases — as high as 64 percent of total defect costs”. That is 64% of errors found on the rightmost part of that diagram.
In a recent Lex Friedman Podcast with Guido Van Rossum — inventor of Python — they talk at length about how 75% of programming is fixing bugs.
In Elon Musk’s recent Biography by Walter Isaacson — in which I was hoping to be full of useful tips about making a hyper productive development team — I was disappointed to find only one (Besides whipping your team into submission). But, I was pleased to find out that it corroborated this issue. With Elon’s adage of ‘Making your requirements less dumb.’
While the cost of fixing a bug is a well cited idea, I believe that this is enormously undervalued and understated.
How to make 5 developers do the work of 25 should be on the front page of every textbook, the first lesson in every computer science course and opening statement of every company’s mission.
My hope for this blog series is to convince readers that the shape of their nebulous inefficiencies can be modeled by this concept. How poor communication, impatience and, ironically, a sense of urgency drags us to the right hand side of this exponential cost scale. And how to fix it.
For that reason, I’m going to do something quite unusual for a technical blog, even my own to date. I’m going to resist focusing on how to optimize the middle bit of this diagram — coding and testing — and focus on the left hand side — requirements and design.
Catching problems as far left to the diagram as possible by communicating effectively, planning well, enabling autonomy and making good ideas go viral.
I’ll then indulge myself and talk about the middle bit like a normal techie, but just a little bit I promise.
Links to be updated on release.
How to make your requirements less dumb
Communicating Effectively I — Acceptance Criteria
Communicating Effectively II — Sequence Diagrams
Communicating Effectively III — The Planning board
Measuring Planning I — Everyones a product manager
Measuring Planning II — Bugs, ‘Bugs’ and Yo-yo jiras
Measuring Planning Misc — Story points are dumb.
How to make your design less dumb
Non Functional requirements checklist
Own your own Infrastructure
Good ideas go viral I — Architectural Design Records
Good ideas go viral II — Ew — Another Company OKRs blog
How to make your coding less dumb
Optimize for cycle time.
Coding standard design records.
Putting it together
Sprint 0
Making your team Happy
