If there were actual accountability, software engineers would have a much better lever against management. For some software this is case. If you write safety critical software you can be held personally responsible for accidents. In those industries engineer pushback is much more effective.
The problem in this scenario isn't software engineering necessarily, it's lack of punishment. Companies do things like this because it's cheap and they can factor in security breaches as simply a cost of doing business. A lot of these problems come as a result of an engineer prototyping or creating something on a tight budget, which then eventually gets deployed out either because said engineer leaves or against their own wishes.
It's similar to housing. Training engineers to build a house correctly doesn't matter if the punishment for the house not meeting code is a slap on the wrist for their employer. Because their employer will just tell them to build fast and ignore the right way to build something.
I'm not a real engineer, just a software guy, but situation feels similar. Responsiblity of outcome and to save money is placed on management who pressure the workers to save money without sharing the bigger picture.
Would it still happen, if responsbility was placed directly on the worker? Why isn't there a review teams were senior enough and given the time to critique an outcome?
Why is it management doesn't understand the consequences of these actions, or are too shameless to admit them and plow ahead?
Sorta. The basis for your concern underlines one of the problems. When such gaffs happen in engineering, the firm is blamed. Within the firm, individual actors are blamed.
In software, on the other hand, your major system might have responsibility for a critical system spread across a total of 1 persons, so he gets all the blame. Is that really okay for one hip-shooter to take this on in the first place?
Unless skin in the game counts as accountability, then that's definitely missing from the list. My previous employer had zero accountability for the people above the software engineers who implemented things and unfortunately these people made all the decisions. You'd have architects and PMs who had all these terrible ideas, tell people to implement these terrible ideas and then blame the engineers when things didn't work. So dumb.
And this is where "software" diverges from "engineering".
Bugs happen in architecture, aircraft, etc. too. the difference is that the actual engineers are paid to have a precautionary approach and spend significant resources to actively prevent bugs from making it into the final product.
In contrast, software is often written to "ship first", be "agile", and "move fast and break things". Yet when it causes problems, they just say "bugs happen", and "it is unfair to vilify them".
Features are not better than reliable security.
And yes, negligence is less bad than malice, but it is still damaging and developers and managers need to be held to account.
If your manager is pressing you to do unsafe crap in too big a hurry, it's your responsibility to push back, and if unsuccessful, leave for saner pastures and make it more difficult for that management to proceed.
Problem is software engineers are replaced with juniors/contractors that probably do not know any better and are only one part of a system that has failed in its entirety.
What sane person would willingly put up code that can kill others on purpose... so we're left with incompetence.
Accountability, if implemented, should be company wide.
Right now issues have passed design stage, implementation, qa... with this sort of failure you have management to blame for not putting up processes in place so its caught / hiring and keeping competent enough people.
This is sort of expected as they optimized cost to the detriment of everything else.
In my opinion, what has been most harmful for evolution of the software engineering profession is the tendency to blame individual developers for not being infallible instead of fixing chronic failures in tooling, processes, and funding.
The medical profession, aviation, even rail transportation [1] have all progressed past the point where avoidable failures are entirely the responsibility of the individual.
Of course, there was resistance in those fields as well because some considered themselves an "above-average" doctor or pilot who didn't need safeguards, checklists, union rules, or laws. But it empirically improved outcomes.
Yours is a good example! I have in a past life actually used the "you wouldn't bolt a new floor onto a building" argument successfully to push against feature creep.
I think even a small amount of accountability would definitely start some much-needed conversations at software companies about things like "do we really need to retrofit this thing onto that working thing?" and "do we fully understand our dependencies and the consequence of merging from them?" and software quality would be better for it. If the consequence of a bug is low, go for it--the accountability should be low, too.
EDIT, just to add another example. I remember when I felt rushed and checked in some client code that did not implement exponential backoff for request failures--it just retried. Of course that code made it to production and our customers started DDOSing our server when a brief outage happened. I felt terrible about it and honestly believe I should have been fired for it. Yes, management rushed me, but they're not the ones that wrote the code. They're not the ones that made an amateur-hour error. It was me.
But generally there is someone that's primarily responsible for the piece of code, be it a manager, engineer, etc. It does suck to be on the receiving end of it and if it's major enough you can be out of a job, but blame should be given to the responsible party/parties and the issue should be handled appropriately as it's more direct than what alternatively happens which is to passive-aggesively handle the situation.
The problem is deciding what is the actual goal of a post-mortem. Is it to fix the problem (and prevent it from happening again)? Or is it to figure out who is the person most to blame so that they can be punished. Because, honestly, you can't have it both ways.
Plus, who makes the final judgement as to the party to be blamed and based on what criteria? Is it QA for not catching the issue, is it the engineer for forgetting to remove some debug code, the tech arch for not properly ensuring there were systems in place to prevent it from occurring in production, the program manager for not pushing back on deadlines that were too aggressive, or the CEO for constantly pushing employees to prioritize revenue over product quality?
Plus, how you handle crises like production going down and being blamed for it say just as much about you as an engineer as does your code.
Or your willingness/ability to find a suitable scapegoat.
I think it puts too much blame on the software developers. Agreed, over-engineering is usually the developers fault. But the fact we don't take time to investigate issues, rather work around them or half-ready stuff gets pushed into the market is rarely the developers fault. These things are decided by management.
A tiny minority of places I've worked do code review for every commit. Or have careful enough processes that they would catch every mistake made by incompetent engineers.
Most companies simply trust their employees most of the time. Hardening a process against programmers you don't trust has a massive cost.
Focusing on anything besides the happy path requires the approval and support to do so from other teams and their respective management and QA.
No, they'd rather not coordinate any of that and just play the blame game.
Many workplaces employing software engineers are actively hostile towards any kind of engineering. I have a very hard time believing anyone writing code is sloppy on purpose. Incentives are often very misaligned. These are pretty much always organizational problems.
Instead of immediately blaming software engineers, you should consider questioning whether it ever makes sense to have non-technical leadership in charge of them. Most places where "real" engineering is done don't have idiots at the wheel.
I have some paradoxical feelings about "blameless" retro culture that I'll try to sum up.
In general, I'm in favor of the approach. I don't think singling people out and bullying or shaming them for their mistakes ever works. I think most well-intentioned engineers will already beat themselves up plenty for making a serious mistake, and they don't need any encouragement to do so. I know I do.
On the other hand, there is a red line. At a place I worked, a DBA was let go after he repeatedly brought production down for 45 minutes to an hour at a time by running intensive queries of his own design for data-gathering, in some cases, after being explicitly told not to do that against the prod database. This was a person whose job description required him to have access to prod.
There were process problems, maybe - being allowed to run whatever queries you want on production under your own authority, sure - but his cavalier attitude towards a production environment was still unacceptable. Process can only help when people are well-intentioned and doing their best; if people are malicious or negligent or just not good at their jobs, adding more process to get around that only makes things worse.
Yea the fix it later approach is an excuse that software engineers get to enjoy. Civil engineers are liable for their mistakes, and face fines/sanctions for their work. Meanwhile, software engineers can get away with half ass logic or mishandling of data and nothing comes of it.
In South Korea, a company with known software vulnerabilities is fined everyday until they fix it. Gives incentive to making sure software does the right thing before it gets shipped.
That may be the case in companies without proper responsibility distinction but in those with (usually the bigger ones), not even small decisions are made solely by software engineers. They are always double checked by the Product Management because any requested change has to come from the Product Management and has to be signed-off by them. In a company like Zoom everything you are seeing in the UI isn’t the result of something that slipped through solely by the engineer but was reviewed and thought out by multiple people who don’t touch the code.
reply