4 ms·
He says that this is a fallacy: > It reinforces the idea that any one person or piece of code can be blamed for a given failure. Why is that a fallacy?
by Angostura 7y ago
He says that this is a fallacy:
> It reinforces the idea that any one person or piece of code can be blamed for a given failure.
Why is that a fallacy?
- ithkuil 7y agoProbably because there is always a bigger picture: culture, process (e.g. testing, code review, time pressure, feature centric performance metrics). Surely, the person making the mistake is the proximal cause for a given bug, and surely all other things being equal personal attitude matters (i.e. a more careless person is going to make more mistakes), but if you zoom out to the big picture you see other responsibilities and more importantly you see opportunities for improvement that vastly exceed the playoffs of "just putting more care" into each commit.
- Angostura 7y agoUnderstood. Thanks for the explanation. I have to say I don’t intuitively like the position, because taken broadly you could conclude that no-one in an organisation is ever personally responsible for their actions, because some system should have prevented the mistake. This feels wrong
- ithkuil 7y agoIndeed, it does feel wrong because it is, technically, wrong. The intent of a "no blame culture" however is to find a new sweet spot on the myriad of tradeoffs an engineering organization does, as an many paradigm shifts we do, it is accompanying with a certain amount of bullshit-sounding maxims meant to be thought provoking and dislodge the readers from their suboptimal local maximums.
- redis_mlc 7y agoConceptually, there's supposed to be a process that reduces errors, rather than relying on each individual to be infallible.
- lenzm 7y agoA more specific and concrete than the culture and process answers is someone should have reviewed and approved the code.
- dingaling 7y agoBut that's just reassigning or distributing 'blame' to the approver. So what is the responsibility of the key-puncher if it isn't turning requirements into robust, correct code? Many comments here seem to suggest that programmers are just there to produce some sort of fuzzy first-stage approximation of what the code could be. In that case, just employ an automated code generator and push the burden onto reviewers.
- muttled 7y agoI think the value is being able to say there were multiple people who didn't catch a bug, so the original coder was acting reasonably.
- jodrellblank 7y agoI think it would be great if we a group of people whose entire job was to watch over the programmer's shoulder, and every time they make any kind of mistake, SHAME THEM. Because shaming the developers is more important than anything else, apparently. All we need is other people who can 100% reliably detect errors in code... oh. They could simply be the developers instead! > So what is the responsibility of the key-puncher if it isn't turning requirements into robust, correct code? How can it be a responsibility to never make a mistake? Nobody can never make a mistake. > Many comments here seem to suggest that programmers are just there to produce some sort of fuzzy first-stage approximation of what the code could be. Many comments here seem to suggest that producing high quality code is a team effort supported by a company or department which values high quality code. If you had mythical no-mistake employees you could do away with most everything else. Why even have tools, tests, revision control systems if you're not making mistakes? And if you are using tools, tests, etc. as part of not making mistakes, why not reviewers, bug testers, quality analysts, as well?
- onion2k 7y agoOne person wrote the requirements and acceptance criteria, another person signed them off, a developer wrote the code (probably using parts of code that many others have written), another developer peer reviewed the code, someone else QA'd the feature, someone else checked the feature was deployable, and so on. Code is never written by a single person on anything but the very simplest projects.
- Hamuko 7y agoI'm not sure if you can extend bugs to that many people, since usually bugs and awful code are not tied into the requirements or the acceptance criteria. That being said, I do hold code reviewers partially responsible if shit gets past to production. A code reviewer is able to see that someone is building SQL from raw input, the QA isn't. And if I see that a developer writes that kind of a thing and another person approves it, the first question I have is if they actually read through the code or just glanced at it.