The power of ZERO

I am not sure if this is a true story, but it’s really really good, so I’ll just assume it’s the truth, and convey it anyway – Because it contains lessons that I think are important.

This happened after World War II, sometimes in the 1950s or something. An American car manufacturer wanted to offshore the creation of some of their components. They had done the math on it, and found that they could save a lot of money by having some Japanese subcontractor create a specific part for their cars. Naturally sceptic, since this was the first time something like this was attempted, they wrote an extremely detailed specification to their Japanese subcontractor, to make sure everything was taken care of. At the bottom of the specification it specified a fault tolerance of 2%, implying they had a margin for error that was maximum 2%.

6 months later, and the Japanese subcontractor was finished with the delivery, and it arrived at some port in America with a boat. The American company was eager to see the results, so they sent a representative down to the harbour to inspect the results. In the shipment, there was one huge package, and a tiny package next to it. The guy who was sent to collect the parts scratched his head, and didn’t understand why there was a smaller package next to the big one, until he read the letter the Japanese car manufacturer had sent together with the delivery. It read …

“We have no idea why you want to have 2% errors, but you can find your 2% errors in the smaller package”

For the Japanese subcontractor, simply the idea of delivering something that wasn’t 100% perfect, was so incomprehensible, that they didn’t even have a vocabulary or mindset that allowed for fault tolerance. Their fault tolerance was always ZERO, period!

We need more people to think like this, especially in the Software Industry …

There is no shame in asking for help

I don’t cut my own hair. Neither do I build my own cars. Instead I pay for these services with money I earn doing my job, which is software architecture and development. This creates a symbiotic relationship, where I can do what I am best at, and everybody else can do what they are best at – Win win!

Unless your core value as a company is to create software, creating your own software is like having your hair dresser building his own car. Everybody can see the madness in this analogy (puuh!), but few can see the madness in having some Acme, Inc. Financial or Medical company building their own software for some weird reasons. If your core business model is insurance, chances are you’re probably not going to be able to take software development seriously – And you shouldn’t either in fact. You should hire somebody else to take it seriously on your behalf. Somebody that has already taken it seriously for decades. Doing things with your “left hand” results in “left hand results”. For a company where software development is a secondary function, software will always be created with “the left hand”. Since your business depends upon software, the same way you depend upon your car, this results in weird situations, where you are no longer able to sustain your company’s operations, because you have built your company on top of “left hand products”.

There is no shame in asking for help

Adding more developers to an already late project

This is a variation of the Mythical Man Month, and probably equally unintuitive. However, the research in this area is bulletproof and has been verified thousands of times by independent researchers, and its conclusion is “Adding more developers to an already late project only makes it later.”

The reasons of course includes that you’re forcing your only productive resource to spend precious time teaching the new developers to understand the existing codebase, in addition to that now the project requires overhead, coordination, and collaboration, adding to its overhead – So while you believe that you’ll be able to finish faster, the exact opposite is the result.

If your job is to move 1000 bricks from A to B, and you’re late, adding more manpower to the job obviously results in finishing earlier. Hence, human experience have taught us that adding more manpower to a job, results in finishing the job faster. Therefor, when a manager is faced with the prospect of not finishing the software project in time, his intuition is to add more manpower to the job. However, you’ll only make it later. Understanding this though, and believing in it, requires huge amounts of experience – Experience most software development managers don’t have. In addition it requires courage, courage to say “NO” when your investors and CEO are telling you to add more resources to your team. However, a mature and experienced software development leader will easily be able to explain this fact to his managers, allowing for the project to finish as fast as possible, without adding to the cognitive load of his team, by adding more manpower to an already late project.

There exists many reasons to hire more manpower, but making the project faster, is not one of those

Deciding it for yourself

If you can’t let the developer decide, who should make the technical decisions in your organisation then? Unless you’re technically skilled, and you happen to know a lot of software development theory yourself, deciding which components to use yourself, is arguably the equivalent of playing Russian roulette with your organisation. Facts are, some 3rd party vendor could probably have waved a beautiful website in front of your face, and you’d happily buy something having zero value, believing in the company’s spiehl about their product’s superiority. Obviously this doesn’t work either.

What you should do, is to align yourself with somebody having the knowledge required, but no incentives in regards to increasing your technical debt. Somebody who have incentives that are aligned with yours – Then you should “outsource” technical decisions to this individual or organisation. This might be a person you employ, for instance a “super duper senior” developer, that has already reached the point, where he have few things left to prove. Or it might be an external consultancy company, that is neutrally assessing components, without any ties to the vendors creating the components they are assessing.

Doing a StackOverflow search, only results in finding whatever tool happens to be most popular at the time you are doing your search, and speaks zero about quality – Since components happen to suffer by “networking effects” – Which implies that adoption speaks nothing about quality, since developers tends to gravitate towards whatever is the most popular component, realizing this will give them a larger chance in the job market to find a better paid and more interesting job later down the road.

You can still have the most intelligent individual making your (technical) decisions, just make sure his or her incentives are aligned towards your first, to avoid experiencing the Cobra effect!

That way the dog wag its tail again, and the inmates are no longer running the asylum

Leaving it for the developer to decide

Most junior and senior developers have one simple incentive; Investing in their own future. The way they tend to do this, is by acquiring more knowledge about potential things they imagine future employers will be interested in. This way the developer makes himself more valuable to any potential future organisation and employer, until he reaches the point that he has made himself indispensable. This creates a problem, which is that the developer’s incentives is in direct competition with his employers incentives. In fact, the incentives are arguably aligned in completely opposite directions.

At the same time, the employer is 100% dependent upon the developer’s opinion and advice, because he is the only one adequately equipped with the knowledge required to make choices of technical nature. This results in a “wag the dog” situation, where the most capable individual to be making a decision, is also the least likely individual to be making the correct decision.

For instance, if you ask an average developer how he feels about some component that solves some specific task, he might find the challenge of creating a similar component more intellectually challenging than simply reusing something existing. This might result in that the developer will be looking for flaws in the component his employer asks him to evaluate, in an effort to discredit the component, trying to convince his employer that he would be much better off letting the developer implement a similar component for himself. This would be in alignment with the developer’s incentives, which is to make himself more valuable.

The expression “wag the dog” implies that the tail wags the dog, instead of having the dog wag its tail. Similar expressions have been made that are of more explicit character, such as “the inmates are running the asylum”. Regardless of how you look at it, if you let the developer alone to mind his own business, he’ll probably do what’s in his own best interest, which is to accumulate more technical debt on behalf of his employer, happily coding away, one line of code at the time – Until the cognitive overload of the organisation as a whole, is so large the organisation can no longer sustain itself.

But why should the developer care? He already have 20 new job offers at LinkedIn, which he now is far more likely to be able to fill, due to that he’s learned all those new and shiny things, while breaking the back of his current employer.

Congratulations, you’ve now entered the “wag the dog” world, happily allowing your “inmates to run your asylum” – You’re no longer in charge of your own organisation, because you allowed your “most competent individual” to make your decisions

This will probably come as a surprise to you, but allowing your most intelligent resource to make the most important and hardest technical decisions, will only result in more intelligent objections against using the most intelligent solutions.