I’ve recently read Bozhidar Bozhanov’s (aka Bozho) article Bad Software is Our Fault. It’s been bugging me ever since. Putting aside the catchy title, the content feels wrong, and in my opinion, it is wrong, deeply wrong. And in the following I’ll give the reasons why. I recommend reading Bozhanovs article before you carry on with this one.
Some introductory words
Before I start, let me introduce Bozhidar Bozhanov: he is definitely not your average Joe, many of you might know him. He’s got a pretty impressive résumé, he is one of the highest-ranking StackOverflow members and on his blog he has some nice high-quality content. So, if a guy like Bozhidar Bozhanov writes
I’m pretty sure it’s our [the developer’s] fault that software is bad, and no amount of blaming the management, the budget, the timing, the tools or the process can eliminate our responsibility.https://techblog.bozho.net/bad-software-is-our-fault/
irrespective of how wrong it might sound or feel, you have to ask yourself: might he be right?
Let’s see what he has to say.
“Bad Software is Our Fault”
His article starts with a hyperbole stating that bad software is omnipresent arguably every piece of software being bad. An explicit definition of what is to be considered bad software is missing, but we can assume that the most important criteria from the author’s perspective are fragility of the code (at least partly expressed as missing tests), presence of bugs and security problems. And why are we as developers to blame for bad software? Because it’s the developers who know the importance of good software and the implications of bad code and it’s our responsibility to create good software.
Bozhanov is aware of possible counterarguments and acknowledges that the whole problem is “actually complicated” but still stresses that the developers are mainly the ones to blame. I very much doubt this is really his conviction, that the developers are the real bad guys here, but I’ll come to this later.
Is Bozhanov right?
Fact is, that there is a lot of badly written software in the above stated sense out there. And we are constantly producing more. Fact is also, that many software projects go wrong. Furthermore, it’s also a fact, that there is generally a great amount of frustration involved when building larger systems.
But: bad software is not our fault.
There surely are cases when a single developer or a group of engineers can be blamed for a deplorable outcome. But these are in my opinion exceptions. It’s a very complex system, socially and technologically speaking, in which the building of software takes place. And I think you can safely make an analogy between people, societies and historically grown large codebases. They all contain odd or unnecessary parts, contradictions, rectifications and who knows what. But they also have a positive commonality: they all work! Some work better than others, of course. But I’ll come to this later.
Let’s see whose fault it is, first.
The problem with responsibility
Philosophically speaking, you could safely argue in most cases in life that everything is everybody’s fault: it’s the individual, but also the context and the society and the culture and the historical development and who knows what. Such an argument is meaningless if you need a halfway realistic solution to a concrete problem.
When building software, you have a series of relevant people besides the techies: managers, product owners and customers. They all greatly influence the outcome. They often directly influence the hopefully beautifully shiny user interface and generally indirectly the structure of the code, the number of tests, security and so on and so forth.
There is also the company’s culture and its organization – let’s not forget the greatly popularized Law of Conway:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.http://www.melconway.com/Home/Conways_Law.html
There is the broader societal culture (including education) and the current technological best practices. They all have a more or less direct or indirect, but ultimately decisive, impact on our software.
So, whose fault is it now?
So, in the end my conclusion is, that it’s everybody’s fault, although I said that this is a meaningless argument? Well, more or less. It’s everybody’s fault and at the same time, it’s nobody’s fault. In most cases you can track down the reasons why a specific piece of software is bad, but the reasons can also be very specific (although they often fit in only a few categories).
If a whole system is flawed, you have to search for reasons on the system level. It’s not the developer’s fault, and it’s not the manager’s fault, it’s not time or budget restrictions it’s ultimately our acceptance of the status quo. And with our, I mean everybody’s. I don’t say any particular individual likes the way things are. But on the whole, we accept the rules of the game: we criticize, but we adapt, we try to change things and sometimes we succeed, but often don’t.
Did Bozhanov believe in what he has written?
I believe Bozhanov is aware of all these aspects, and this is why I don’t really take his article seriously. But others might, and this is why his post has been bugging me and I felt the need for a rectification. So, here it is once again:
Bad software is not our fault.
Bozhanov asserts in another article Solving Problems Properly Is Often Not Viable – some one and a half years after blaming developers for almost everything – that the economic value of properly solving problems is often low.
He finishes the text with a gloomy outlook:
And we will continue that way, pushed by standards and regulations when nothing else helps, to a messy gradual improvement. But it won’t be worth the investment to do things right – why would you invest millions in quality software development when it will marginally affect your business? It’s only worth to get things to barely work.https://techblog.bozho.net/solving-problems-properly-is-often-not-viable/
Is the glass half empty, or is it half full? It depends.
Bad software is not our fault
But what I find important for all of us to remember, is that our way of working got us this far.
Yes, we muddle through.
And no, this is not good.
And yes, we should fight the current problems of our métier.
But please don’t forget: the system might be severely flawed, but it works. It surely got us this far.
And, in the end, it is really amazing how software changed the world in merely a few decades despite our way of working, despite all the bugs we produced and despite all security issues we created[i].
So please, don’t say any more that it’s us developers to blame, because bad software is not our fault. 😉
You might also like the following articles or book reviews:
- Heidi and autonomous herding
- Ilya Bibik – How to Kill the Scrum Monster: Quick Start to Agile Scrum Methodology and the Scrum Master Role
- The complexities of a Java developer’s world
- Daniel Kahneman – Thinking, Fast and Slow
- Reflecting on my college years
- David Thomas, Andrew Hunt – The Pragmatic Programmer (20th Anniversary Edition)