This would be a reasonable comparison if 90% of software developers could reliably produce bug-free code. This would be a (maybe less) reasonable comparison if 75% of software developers could reliably produce bug-free code. This would be a middling comparison if 50% of software developers could reliably produce bug-free code. This is a completely unreasonable comparison given that there have been 0 software developers ever, in the history of software, who have been able to reliably produce bug-free code. So yes, software development is orders of magnitude more difficult than plumbing, dentistry or electrician(-ing?). If you think it isn't, please feel free to jump in and prove all of us wrong.
This is quite an exaggerated point; the number of people imprisoned for making mechanical, civil, or electrical engineering errors is very close to zero in the US.
I think more programmers have actually been charged than any other field, although I can't quote a statistic to back that up.
Also the environment in which this happens is completely irrelevant.
By the way. A dentist gets to try on fake tooth before drilling a real tooth. They actually don't have a choice, that's part of the mandatory training. Doctors gets to train on real people too, medicine schools go to great length to procure bodies for training purpose.
In programming, one would be lucky to get any sort of test environment.
Are you saying you went straight to writing production code before you ever studied any software engineering? Sounds unusual for practitioners of an industry endowed with such a critical responsibility.
A dentist can easily kill someone through malpractice... There's no code review, there's no test environment, and there are always difficult (often time-sensitive) decisions to make and difficult people to deal with.
If all you know is estimating story points and merging pull requests to make your burn-down chart look pretty you probably shouldn't be so confident that your profession is more difficult or more superior than one that you have no understanding of.
Medical staff have the equivalent of code review and test environments. Non-routine operations have always multiple people in the room. They have bodies to practice on.
Do yourself a favour and drop the attitude. Medical and software industries both have some very difficult jobs.
>It reinforces the idea that any one person or piece of code can be blamed for a given failure.
That can absolutely be the case. How could it not sometimes be the case?
>Short of malice, this is never the case.
Never? Outside of somebody deliberately harming a system, there has never once been such an instance?
>It gives the impression that, when you wrote the code, you should have written it better. This is a counterfactual that rarely holds up to examination.
Lots of assertions in this piece with no supporting information. There are plenty of reasons substandard code is written by some individuals. Laziness is a big one. Apathy is another.
>It positions shame as the correct emotion to feel about bugs in your code: if you were a better engineer – a better teammate – the bug wouldn’t exist.
Call it whatever you want, but concern is certainly warranted.
>If you’re a more senior engineer on your team, the effects of these anti-patterns are magnified: people see you apologizing for bugs, so they think that they should be striving to write bug-free code. They may feel ashamed if their code has bugs.
People look up to experienced individuals within their profession. In fact, I would argue that it is even more important these senior individuals are able to accept responsibility and act accordingly; that's setting an example, something from which everyone will benefit.
Why not a little bit of both? Can we not think about system and data driven improvement while also at the same time apologize for our mistake?
"Just be more careful" has pretty much proven not to be a successful strategy to reduce defects.
I agree but this point is orthogonal to the main point. Plumbers and electricians build to code in an environment where physical reality remains constant and they operate on expected inputs. A civil engineer is not held to account for a failure if gravity suddenly reverses itself. If I shock a circuit board with static electricity and it fails is that an electrical engineer's fault? If I put 20,000 psi through a household plumbing system and it fails is it the plumber's fault? These designs are only expected to operate in a narrow range on a small number of expected inputs / variables and that is easier.
Software can basically expect infinite permutations of inputs at any time and is expected to give good outputs and no bugs 100% of the time?
I mean in electrical engineering, idea-to-working-prototype involves a lot of design and assembly first. In structural engineering, you just can't build a bridge on your own. It goes on.
While in software development, I can cough up ten distinct features in a day if not more without forward design or testing.
A hammer that melts in a furnace is considered a bug?
The possibilities and test paths a piece of code can possibly take exceeds a very large number in a complex software application.
Zoom should work and gracefully fail if there is not a single microphone device found on the client’s PC.
We are pretty good at writing software with a very small number of bugs, it just costs a few orders of magnitude more than normal software.
Imagine if an electricians invented new types of wires for every job they did
I'm not sure why software is the way it is, maybe it will be more like a trade in a few decades...
In buildings with nontrivial electrical systems, shit hits the fan really quickly too. Just look at the absolute mess that is the fire prevention system in Berlin's new airport for example.
Copper, plastic, other things which I have no authority to talk about, were all complex at one point in time
You do make a good point about scope creep, I wonder if the early days of electronic had a similar problem because nobody knew what they wanted or what was possible?
Very interesting to think about IMO
So the analogous question would be whether someone who has worked as a plumber has ever heard a coworker plumber apologize for messing up a job. I'm hoping the answer to that is yes. A plumber apologizing directly to a customer would be more analogous to a company making a public announcement about a bug, which is a different issue than how responsibility is determined within a team.
Maybe there's a reason you rarely hear one category apologizing and hear the other category coming up with excuses.
Failed you? This sounds either very entitled or sensational. Has software caused you major grief in any way financial or the loss of limbs or loved ones? While this happens, very few people are affected by bugs in such a way, at least confirmed.
Many people have been significantly affected by software bugs. Therac-25[1] is one I constantly remind myself of; it killed 5 people. Here's a list for further reading: https://en.wikipedia.org/wiki/List_of_software_bugs
I'm not sure what your definition of "very few people" is but we'd all do well to aim for 0 adversely-affected people as a result from using software we write.
> I'm not sure what your definition of "very few people"
I think my definition is about the same as every accepted definition of "very few", the number of people affected by such bugs falls within this definition, considering how many users software has.
> Many people have been significantly affected by software bugs. Therac-25[1] is one I constantly remind myself of; it killed 5 people.
5 does not fit the definition many in anyone's book.
...
>I was asking OP if he was personally affected
So 5 people dead is insignificant, but a single person, adversely affected, is cause for concern?
Well, IIRC, there's Watership Down, a literal book, but I assume you meant that figuratively.
This is an incredibly ignorant statement. Have you worked in that profession? Any professional engineering roles?
But that all doesn't really matter because the statement becomes meaningless when qualified with "Depends on the project[...]"
I would be interested in some experiments of average developers learning average plumbing vs average plumbers learning average development. I'd wager theres an order of magnitude difference in the results(time spent, quality etc).
Besides all this incredibility, yes, I do work professionally in an engineering role.
Limiting a statement is not the same as a completely making it meaningless. Of course there are plumbing projects, which are more complex than a static blog. Besides that, I would also like to remind you of the little part of the phrase "I'd wager that". I did not know, that it is an "ignorant" statement, to express ones believes.
In the UK...
Dentists: you have to have a BDS or BChD degree from a dental school at a university
Plumbers: have to get NVQ diploma as well as pass Gas Safe accreditation to fit boilers and heating systems, plus get a CSCS card to work on construction sites
Electricians: have to get an NVQ diploma, and to work in construction, they must also have an ECS card to work on a building site
Software developers: [this is left blank as an exercise for the reader]
In fact, there's a (very popular) school of though that the more credentials you have, the less qualified you are to develop software: https://blog.alinelerner.com/how-different-is-a-b-s-in-compu...
“Thanks for reporting this, I’ll take care of it” is accepting responsibility while avoiding a morality judgement.
Why wouldn't this be acceptable? They source that crown from a supplier, and apparently there was a fault with it.
Would you accept such nonsense from your plumber, or your dentist, or your electrician?
Software engineering is one of the most fundamental building blocks of modern civilization, and yet it continues to be so fragile because of this kind of cavalier attitude.
Also, apologizing doesn't mean you have a moral failing. It means accepting at least partial responsibility, and being humble about it. Any good org knows that you don't just design your system with the hope that people won't screw up, you need to design it to work despite some amount of screwing up. But in either case, it is still both an individual and collective responsibility.