Software development is a loser’s game
Great code doesn’t save you, but bad code will kill you #HoskWisdom
I’m not saying developers are losers but most software developers are not beating software development, software development is beating them.
The reason developers struggle is because they don’t know what game they are playing or the best tactics to use.
You need to know what game of software development, so you can play effectively.
In the creative process of writing code, it’s not if the code will be wrong, it’s when the code will be wrong and fixing it in the easiest way possible.
Winner and losers
In the essay Loser’s Game by Charles Ellis, he notes that professional tennis is a winner’s game where players win points. Amateur Tennis is won using a different strategy of keeping the ball alive and letting your opponent beat himself.
“In expert tennis, about 80 per cent of the points are won; in amateur tennis, about 80 per cent of the points are lost. In other words, professional tennis is a Winner’s Game — the final outcome is determined by the activities of the winner — and amateur tennis is a Loser’s Game — the final outcome is determined by the activities of the loser. The two games are, in their fundamental characteristic, not at all the same. They are opposites.” Charles Ellis
The same game but the effective strategy depends on who you are playing with
“Expert tennis is what I call a Winner’s Game. Victory is due to winning more points than the opponent wins — not, as we shall see in a moment, simply to getting a higher score than the opponent, but getting that higher score by winning points. Amateur tennis, Ramo found, is almost entirely different. The amateur duffer seldom beats his opponent, but he beats himself all the time. The victor in this game of tennis gets a higher score than the Opponent, but he gets that higher score because his opponent is losing even more points.” Charles Ellis
The game of software development
I have worked in software development for 20 years, worked on many projects with many software developers. I estimate 80 percent of software developers are amateurs and 20 percent professionals.
Why do I say this?
Amateur software developers dislike
- Standards
- Unit testing
- Design patterns/SOLID principles
- Learning and setting DevOps and ALM (They like using it)
- Fixing the build
- Code reviews
- Code Analysis/Solution checking
If you were trying to sabotage most development teams, you wouldn’t do the steps above because most developers on a team are not professionals.
“The way to avoid mistakes is to be conservative and keep the ball in play, letting the other fellow have plenty of room in which to blunder his way to defeat, because he, being an amateur (and probably not having read Ramo’s book) will play a losing game and not know it himself.” Charles Ellis
Most developers underestimate writing code and overestimate their ability to create working software. They approach writing code assume writing code is easy and the code will work first time.
Amateurs
If the majority developers are amateurs, we should approach software developer as a loser’s game and focus our efforts on reducing mistakes that amateurs are prone to making.
The goal of the amateur developer is to write code, other activities slow the process down. The other step above are to create simple code, find bugs earlier when it’s quicker to do so and focus on quality. ALM/Devops allows quick error free deployments, which enables fast feedback.
The best way to write code quickly is by focusing on quality and reducing bugs, not by writing code faster.
The cost of bugs, errors and mistakes is more important the larger the project/development team. Problems on large teams can delay many people and the focus should be on stopping by implementing the activities in the list above.
I have worked on projects where bugs kill momentum, bugs found in the latter stages lose the confidence of the users and risk go live.
Invert
If we invert software development, the goal isn’t then to write code that works, it’s spending time on avoiding writing poor quality code and bugs.
“It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent.” — Charlie Munger
Amateur developers believe writing code quickly is the fastest way to create production ready code. The big methods and complex code create a code base that grows in complexity and makes development harder with every line of code added. This is an approach only works on small projects with one or two developers working on it.
Cost of bugs
The further you find a bug away from the time it’s written, the longer it takes to fix. E.g. if you find a bug in production, understand it, recreate it and then a developer has to fix the code and deploy and test in each environment until production.
If you find the same bug with a unit test, you will fix it quicker and reduce the impact on other developers and testers.
We can add simple steps into the development process to catch bugs, and in a game where bugs cost a lot of time and drains confidence from the customer, it’s the most effective approach.
When we know most of the development team are amateurs who are prone to beating themselves and the development team, it makes sense development teams put more emphasis on stopping bugs than assuming everyone is a professional developer creating great code.
Success in development is not about creating code correctly first time, it’s about avoiding the many ways of failure.
or to quote Charles Ellis
“Professionals win points whereas amateurs lose them.”
