There Is No Bad Code
A short reflection.
There is no bad code.
It just does the wrong thing very efficiently.
The words effective and efficient both mean “capable of producing a result,” but there is an important difference. Effective means “producing a result that is wanted”. Efficient means “capable of producing desired results without wasting materials, time, or energy”.
— The Britannica Dictionary: How to Use Effective and Efficient
Your bugs?
Nothing wrong with them. The code simply does the wrong thing. It was not intended. But that’s what it does now.
What will you do about it?
Some don’t ship it.
They understand that it’s not functionally doing what is expected, and so take the time to revise it until it—at least seemingly—does the right thing. If someone ever knows what it actually should do. When they do (think they) know, they might add tests, or even use a test-driven approach, to get to that state in which they have confidence that what is shipped is what is expected.
Some ship the code.
They might know that it does the wrong thing. Maybe they hope no one will notice. Sometimes no one does.
Some are forced to ship it.
They are not measured by outcome but by output. They spent their X number of hours. Time’s up, boys and girls! Fuck it, ship it. The task/scrum/scum master has spoken. The whip has been cracked, and so has the will. Word is bond, ye slaves, and nothing is more sacred or more bondaging than story points and “burning down” at an increasingly heart-racing pace. If a forensic psychologist would come in, pyromania would have been declared long since.
Some let the customers find the problems.
This is fine if the loop is monitored and automated (et cetera, yada yada…). But that’s not the persona I’m thinking of.
No, these are the truly despicable bad guys who let the customer feel the pain and have no automation to alert on turds hitting rotary fans. No—they let them call in. That’s the sign of a true, loyal customer—the one who dares to struggle with Customer Support. For free, with nothing material gained from this ordeal.
A true Customer™. One all organizations are in awe of. One to be proud of. Such customership is forged in agony. How do you make customers if not through menial oppression?
The real issue is why do we not let the code do the right thing?
Some don’t know.
They don’t have a clear concept of what is expected. They trust their masters, often not so wisely. Sometimes the masters plot and create an organizational chart that is massive and detailed, handpainted by exotic artists, embellishing the stately patrons with long titles, as a means to legitimize the fog in the crystal ball. It will wear off once the re-org is launched and rolled out. The masters are to be trusted.
Others do their best to experiment and create shorter loops between users, the team, and the masters. This has actually proven quite successful for many. As always, the distance between those who do and those who pose and pretend is abysmal. Many talk; few do the walk.
Poseurship is a trait to behold, like a bum fight with scholars: Fine words and poor coordination of limbs and power.
Some know.
Here, for once, we have those who manage to build something that provides value, and do it well. But also, in this category, are all those who experience fragmentation and politicization of their organization. What makes sense at one end is like a bunch of bananas dipped in crazy sauce in the other end. Nothing good will come from such disintegration. Yet it’s common.
Humans are 99% chimpanzees. That’s good to remember and makes me able to sleep at night.
You don’t need to be reminded by something like Time Magazine’s The 50 Worst Inventions (including such abominations as subprime mortgages and asbestos) or the Museum of Failure—you simply have to go to work, if you are an IT professional.
Because that’s what many of us do: We try our best to make something that is good at the right thing.
But what is right for us? It seems no one really knows.
And so we are back at our crossroads once again.