Bad Software Is Our Fault
Bad Software Is Our Fault
Is bad software the fault of the engineer? Find out what one developer has to say in regard to this statement. Do you agree?
Join the DZone community and get the full member experience.Join For Free
Do you know who is accessing your valuable data through your APIs? Discover how
Bad software is everywhere. One can even claim that all software is bad. Cool companies, tech giants, established companies, all produce bad software. And no, yours is not an exception.
Who's to blame for bad software? It's all complicated and many factors are intertwined - there are business requirements, there's organizational context, there's lack of sufficient skilled developers, there's the inherent complexity of software development, there's leaky abstractions, reliance on third-party software, consequences of bad business and purchase decisions, time limitations, flawed business analysis, etc. So yes, despite the catchy title, I'm aware it's actually complicated.
But in every "it's complicated" scenario, there's always one or two factors that are decisive. All of them contribute somehow, but the major drivers are usually a handful of things. And in the case of base software, I think it's the fault of technical people. Developers, architects, ops.
We don't seem to care about best practices. And I'll make some nasty generalizations here, but bear with me. We can spend hours arguing about tabs vs spaces, curly brackets on a new line, git merge vs rebase, which IDE is better, which framework is better and other largely irrelevant stuff. But we tend to ignore the important aspects that span beyond the code itself. The context in which the code lives, the non-functional requirements - robustness, security, resilience, etc.
We don't seem to get security. Even trivial stuff such as user authentication is almost always implemented wrong. These days Twitter and GitHub realized they have been logging plain-text passwords, for example, but that's just the tip of the iceberg. Too often we ignore the security implications.
"But the business didn't request the security features," one may say. The business never requested 2-factor authentication, encryption at rest, PKI, secure (or any) audit trail, log masking, crypto shredding, etc., etc. Because the business doesn't know these things - we do and we have to put them on the backlog whereas we should fight for them to be implemented. Each organization has its specifics and tech people can influence the backlog in different ways, but almost everywhere we can put things there and prioritize them.
The other aspect is testing. We should all be well aware by now that automated testing is mandatory. We have all the tools in the world for unit, functional, integration, performance and whatnot testing, and yet many software projects lack the necessary test coverage to be able to change stuff without accidentally breaking things. "But testing takes time, we don't have it." We are perfectly aware that testing saves time, as we've all had those "not again!" recurring bugs. And yet we think of all sorts of excuses: "let the QAs test it"; "we have to ship that now, we'll test it later"; "this is too trivial to be tested"; etc.
And you may say it's not our job. We don't define what has to be done, we just do it. We don't define the budget, the scope, the features. We just write whatever has been decided. And that's plain wrong. It's not our job to make money out of our code, and it's not our job to define what customers need, but apart from that everything is our job. The way the software is structured, the security aspects and security features, the stability of the code base, the way the software behaves in different environments. The non-functional requirements are our job, and putting them on the backlog is our job.
You've probably heard that all software becomes "legacy" after 6 months. And that's because of us, our sloppiness, our inability to mitigate external factors and constraints. Too often we create a mess through "just doing our job."
And, of course, that's a generalization. I happen to know a lot of great professionals who don't make these mistakes, who strive for excellence and implement things the right way. But our industry as a whole doesn't. Our industry as a whole produces bad software. And it's our fault, as developers - as the only people who know why a certain piece of software is bad.
In a talk of his, Bob Martin warns us of the risks of our sloppiness. We have been building websites so far, but, more and more, we are building stuff that interacts with the real world, directly and indirectly. Ultimately, lives may depend on our software (like the recent unfortunate death caused by a self-driving car). And I'll agree with Uncle Bob that it's high time we self-regulate as an industry before some technically incompetent politician decides to do that.
How? I don't know. We'll have to think more about it. But I'm pretty sure it's our 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.
Why do I insist on bashing my fellow software engineers? Because if we start looking at software development with more responsibility, with knowledge of the fact that if it fails, it's our fault, then we're more likely to get out of our current bug-ridden, security-flawed, fragile software hole and really become the experts of the future.
Published at DZone with permission of Bozhidar Bozhanov , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.