Switch from apologizing, to thanking the person that found the issue. Profoundly different effect.
One is all-about-you. The other is a team-building action, recognizing the folks who normally get a lot of grief(denial; accusations; ignoring their input). Testers respond amazingly when they're heard and treated seriously.
It is so profound, let me tell you an anecdote. My test lead had gone to a conference (they have them!) He was in a bar at the end of the evening, shooting the breeze about all the type-A developers they have to deal with, with a group of attendees.
He told the group "I have a guy in my company, I find a bug, he thanks me! Then works closely to categorize and then fix it. No complaining; no yelling. He just says Thank You! and gets on with it. Says I saved him embarrassment if the bug had gone any further, and saved the company money."
Another guy in the group, from a different company in a different state, said "I know who you're talking about. I'll write his name on this napkin, you tell me if I'm right".
He wrote my name and passed it over.
They had never met; never working the same companies at all. Were in different places in their careers.
But I had worked with both of them. One of them, 8 years before. But still, still I was the only developer either of them had ever dealt with, that responded positively to a bug report.
I can't believe this is rare. Well, I can, but it makes me sad. Even if you do apologise, isn't it obvious that you want to thank and/or compliment the person who made you wiser about your slips/mistakes? I think the entire team I work in does, and I've only ever encountered a few people that don't. I suspect I'm very fortunate/spoiled.
I mean, in the end, the person notifying you of your mistake didn't create that mistake. All they did was take the state of the world from "you don't know about your mistake" to "you are aware of your mistake". Other than edge cases of plausible deniability, this can only be a good thing, right?
What is funny is sometimes I'll run into a problem customer that other developers complain about and I'll profusely thank that customer for finding the bug (even if they are being jerks about it).
After a few rounds of that and they think they're a valuable power user with lots of insight who is saving us all. (Doesn't matter if it is true or not.)
Suddenly they bring me bugs all happy as a clam that they found something that nobody else could (again doesn't matter if it is true or not), and they're all proud and in a much better mood and feel better about the product.
FWIW, I always thank people for their bug reports on my open source projects, simply because they took their time and helped to improve the software. Also, it encourages to do bug reports in the future. As a solo maintainer, I rely on other people testing my code. I only apologize for a bug if it caused the user a great deal of inconvenience. Generally, my experience as an open source maintainer is rather pleasant because all of my users are very grateful that the software exists in the first place :-)
Yes, it did happen. One had gone from our startup, to a senior test Engineer at Microsoft. The other has gone thru Engineering test lead, to VP Engineering, to owner/operator of a Falafel joint.
Anyway it was 15 years ago. Things were different then.
Why do software engineers constantly try to project that they are a special snowflake of a profession?
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.
> Would you accept such nonsense from your plumber, or your dentist, or your electrician?
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.
Look, if I genuinely screwed something up, sure, I'll apologize and either way I'll fix it. But if I didn't test some corner case because the software takes 30 minutes to build, another 30 minutes to start up, and can't be run without a live database and crashes with an out of memory error after it runs for more than 30 more minutes and no time has ever been allocated to improving the code quality because that's "low priority to the business" and the fix was one of the 20 I had assigned to me in this two-week "sprint", then I don't owe anybody an apology. If you think you can find somebody better, be my guest.
> In some cases imprisonment and an utterly ruined career are the result of mistakes
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.
Try working in military applications, aerospace, tax software, medical devices, banking. Making one mistakes can affect the fates of hundreds if not millions. It's way more responsibility and risk than the job you quote.
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.
> A dentist gets to try on fake tooth before drilling a real tooth.
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.
A software engineer can easily kill tens of people with a typo. Medical devices have a ton of software and it's only increasing.
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.
I think the important point is to let go of ego issues. A bug is a technical problem, how do we address a technical problem? By being level-headed and not playing the blame game. Being sorry doesn't add any relevant information and generate a strange atmosphere, like admitting a moral failing really. Any matter of substandard performance is better dealt by the management, well outside the scope of bug fixing.
No, elaborate insistence on repentance rituals, shaming, and ideologies of "personal responsibility" over systems thinking and data driven improvement is all about ego.
This is not a cavalier attitude. The article is not minimizing the harm caused by bugs. It is attempting to direct the blame away from individuals and towards systemic causes of defects. This is necessary to be able to effectively address them.
"Just be more careful" has pretty much proven not to be a successful strategy to reduce defects.
>Why do software engineers constantly try to project that they are a special snowflake of a profession?
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?
(IMO / 2 cents) because as a software developer, you can create a huge amount of functionality in a short amount of time if you cut some corners. This just isn't the case, doesn't have nearly the fast return-on-investment that you get in other fields of engineering.
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.
When you design a hammer and sell it to the end user, there are limitations on how they can use it. You simply cannot encompass and address every situation that the end user would subject the hammer to. What if they left the hammer in a hot 1500 C oven? The designer cannot design it such that it can universally work in every situation. There are usage guidelines and limitations.
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.
Actually situations like this are still considered a bug in software. It is always the responsibility of the software to be resilient against externalities.
Zoom should work and gracefully fail if there is not a single microphone device found on the client’s PC.
No, it continues to be so fragile because software engineers build virtual machines with enormous numbers of moving parts that need to change all the time but nobody wants to pay the price for exhaustive testing (not to speak of the price of formal verification).
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.
This is the same thing I was thinking. We write imperfect software because the market (and the law) does not incentivize the significant extra work required for perfect software. Blaming individual engineers or organizations for that doesn't make any sense.
No it's because a piece of software with a few hundred thousand lines of code has a state space that boggles the mind. And then that software interacts with a dozen other services of similar size. And then new features need to be added every few weeks. It's completely incomparable to wiring up a normal house.
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.
I see what you're saying, but I think electronics is equally or more complex than software, but over a longer time period
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?
I'd think so. If you were to install one of Tesla's early first AC motors, it'd sometimes do unexpected things or stop working intermittently, I suppose
This is about the dynamic between people within the organization (coworkers, boss, etc.), not about external communication to customers. That is, we aren't talking about whether an individual software engineer should apologize to the customer or the end user.
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.
And yet my house has never caught fire due to a miswiring or got flooded due to a misplumbing but let me not even count the ways in which software has failed me.
Maybe there's a reason you rarely hear one category apologizing and hear the other category coming up with excuses.
> but let me not even count the ways in which software has failed me.
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.
When someone pays for software, they are perfectly entitled to expect it to be fit for purpose. Failures don't have to cause major grief for me to be justifiably irritated and to expect redress. A conscientious developer should apologize for wasting people's time or selling them products that don't do what they are supposed to.
>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.
Read my reply again, note especially the part "While this happens". Obviously I am acutely aware of what you are saying, no matter how many Wikipedia articles you link, so your comment is not only superfluous but also makes no sense, as I was asking OP if he was personally affected in such a way because he seemed bitter. Your reply does not answer this, and you should let him answer for himself.
> 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.
Plumbing and electrical doesn’t change all too often. Once you learn the ins and outs it doesn’t change much over your career. Not the case with software development.
I know people who’ve programmed microcontrollers in C all their lives and still written bugs. It’s not like switching tooling once in a while is the source of bugs.
The worst thing code I have written ever did was cause a small power outage. But that was a one-time thing, I haven't had the opportunity to write code that even could do that in years.
Plenty of people are hurt or killed through clerical errors by medical professionals, but you're not going to get anyone admitting that. Even for something simple, if you have any accusation to make in a medical context, it's probably time to evaluate your options and consider a new doctor, and only then make your accusation.
With plumbing the tools of the trade have been the same for 100+ years. Pipes, wrenches, valves. It seems like every two years in the software engineering realm you have to learn to use a completely new tool in order to be valuable to a company.
Make sure you're comparing them equally here. So don't compare the plumber coming to your house to fix a problem with the sink, with a software engineer working at a airspace center for example. The home-plumber vs the home-hacker and the enterprise-plumber vs the enterprise-developer is a more fair comparison, and while I'm not a plumber, I think you underestimate the complexity they deal with when working on a larger scale.
I've worked as a structural engineer (EIT) before. There are some situations where structures are complex (earthquake modelling and really large bridges) but honestly software is way, way more complex than structures. I'm not saying I agree with the contributed article (I think people should be sorry for bugs they missed, at least to a point) but I have some empathy for the fact that even seasoned developers let bugs in despite all the tests, and lints, and monitoring, and best practices. Sometimes you just don't anticipate something and nobody else around you did either. It's a more complex domain than the forces in the physical world, and unlike the physical world in most cases, the same mistake goes to everyone. One electrician screws up one time and one house burns down to the ground. One software engineer screws up one time and well everyone's shit breaks at the same time.
I think it's normal to assume averages when comparing things.
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).
Really incredible, when you have to go through university for at least 5 years, with heavy technical and at least for me mathematical lectures. Also incredible, when the complexity of IT systems is ever rising. Incredible, when we basically have to build mathematically correct systems, to make sure things work exactly like they should, including weird user wanted behavior, just for historical reasons. Also weird, that working in IT often requires a degree and that degree has requirements in educational background, which do not exist for plumbing.
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.
> Would you accept such nonsense from your plumber, or your dentist, or your electrician?
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]
I hear from plumbers and electicians all the time that the last guy to work on something was an idiot. Medical errors are routine and managed through a combination of procedure and insurance, not by admonishing doctors.
“Thanks for reporting this, I’ll take care of it” is accepting responsibility while avoiding a morality judgement.
I totally agree with you. In fact, some branches of software engineering do have equally high standards as other engineering fields. If you write the software for a medical device or an airplane, you better make sure it doesn't have any critical bugs, otherwise people will die. If you write audio software for professional musicians, you better make sure that it doesn't have any critical bugs, so you don't ruin a live show. I think people claiming that nobody can write bug free code and you shouldn't even try simply work in environments where failures don't cause irreversible harm.
Everything exists in an economic context. Errors in plumbing, dentistry, and electrical work can result in thousands or hundreds of thousands of dollars in damage, and they often can't roll out a fix in a matter of hours. Some software bugs can also result in lots of damage (financial/health data security, etc), and we do take those bugs seriously via compliance (although compliance isn't a guarantee for good software just like it's not a guarantee for good dentistry). But no one is going to pay for the effort required to perfect every software release, nor should they.
Yeah I'd accept it from my dentist. A couple of years ago, they gave me a dental crown for one of my upper right molars. Two months later, it chipped. It felt weird in my mouth.
Why wouldn't this be acceptable? They source that crown from a supplier, and apparently there was a fault with it.
Sure you have a point, but then I do not force my plumber to do his job in far less than the time required, keep changing the plumbing requirements and make him start before the final requirements are seven known.
You are right. This is the flip side of not treating software as an engineering discipline. But both parties are at fault. The business treats us like non-engineers and we don’t behave like ones.
> It reinforces the idea that any one person or piece of code can be blamed for a given failure. Short of malice, this is never the case.
If I make an off-by-one error, where, other than me, did it come from?
> 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.
If I make an off-by-one error, I could have done better.
> 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.
It is not about shame, it is about responsibility.
> 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...
We should all aspire to do better.
> ...They may feel ashamed if their code has bugs.
See my previous comment on shame.
About the only thing that annoys me at work is people trying to deny responsibility for their actions (or lack of them.)
>If I make an off-by-one error, where, other than me, did it come from?
Could have come from confusing documentation on the appropriate bounds, could have come from an unclear exit condition for the loop, could have come from contradictory requirements that had no real solution. That you're the agent at the end of a chain doesn't release the chain from responsibility.
> If I make an off-by-one error, I could have done better.
People often miss targets by small amounts. Tyson Gay is only behind Usain Bolt in the 100 meter world record by 0.11 seconds[1]. Is that all on Tyson not working hard enough, or are there maybe other factors?
> It is not about shame, it is about responsibility.
If it's about responsibility, then there should be a process for understanding why engineers end up writing bad code. Of course it can be that the engineer made a mistake, but it can also come from many other factors. Assuming that the person who wrote a bad line of code should "take responsibility" puts the cart before the horse in building a good process.
After all - it's the compiler that emitted machine code that did the wrong thing. Maybe the compiler is the real villain here.
>>If I make an off-by-one error, where, other than me, did it come from?
> Could have come from confusing documentation on the appropriate bounds...
If you are blindly following direction to that level of detail, are you a programmer or a typist? Maybe there will be corner cases like this, but they do not invalidate my point.
> Tyson Gay is only behind Usain Bolt in the 100 meter world record by 0.11 seconds.
This is not a comparable situation. For one thing, off-by-one errors are not off-by-0.11 errors, though the difference is more significant than that.
> If it's about responsibility, then there should be a process for understanding why engineers end up writing bad code.
Of course, and there is no shame in that. Part of answering that question, and in becoming a better programmer, comes from acknowledging and understanding the mistakes we make (this is an important part of aviation safety, and the last thing an instructor wants to see is a student who has a tendentious excuse for every lapse.)
And no-one is responsible for things they cannot control, unless they set them in motion themselves, or ignored the likelehood that they could happen.
>> We should all aspire to do better.
> I agree!
Yes! this is the most imprtant point - and there is no shame simply from falling short.
Well put. I am amazed at the replies to your comment.
My thoughts are, it's all about accountability. Good development and, more broadly, learning, rely on effective feedback loops. "Did it work? Y/N and why?" repeated over and over.
When you blur accountability in an effort to be empathetic, it messes with this loop. You've changed the definition of "it" to not be fully what was in your control, and then as a result don't have a clear action you can take to do better next time. This, to me, is how you wind up with 10 1 year experiences.
To summarize, even if a bug is only 10% your fault, be accountable for it, because that's a clear signal towards something you can improve. Accountability doesn't mean falling on some sword, you can also own improving the things that lead you to make this mistake. The difference is, you're taking action to improve things, versus distributing blame (which I find often leads to "what can you do" type mentalities, leaving all the broken things there for the next unlucky person)
I think in some ways the author is on their way to making a greater point about making mistakes without quite hitting the nail on the head.
Guilt and shame are the enemy of responsibility and those who seek to inflict guilt and shame are toxic to any organisation. They encourage those who are focused on maintaining an image of never being wrong while punishing those who seek to better themselves and obviously make mistakes as they grow.
I managed to remove everyone from my life who inflict a guilt or shame (luckily not any family members) and life has got way better since then both personally and professionally.
You make a valid point here. In a toxic environment where guilt and shame are tools of oppression, you do not, in practice, have the option to be candid.
> It is not about shame, it is about responsibility.
Assigning personal attributes (responsible/irresponsible) like this is a sub-optimal strategy for improving human performance. It conflates what a person does with who they are. What a person does is malleable, and their performance can be improved with teaching, practice, better techniques, etc. Experienced teachers understand this and avoid turning a discussion about correctness into a discussion about character, as it's counter-productive, and reinforces the narrative that performance is based on innate character, not on hard work.
aspiring to do better does not mean aspiring to write bug free code. One is a nearly impossible goal (not over time but certainly at first and certainly when balanced by other constraints)
> About the only thing that annoys me at work is people trying to deny responsibility for their actions (or lack of them.)
There's a difference between denying responsibility and apologizing.
What I do when I find a bug or someone points it out to me is say something like
"I see that. I thought the xxx did yyy but that's clearly not the case. Now that I think about it xxx may also do zzz, is there anything else you can think of that I should take into account"
Or more simply. "Thanks for catching that. I'll put it in the bug tracker. Is this a showstopper for your work?"
I think there is also a difference between apologising while feeling guilt or shame, and apologising and acknowledging that you’ve inconvenienced someone without any of the guilt or shame attached.
apologising as you promote is a forward-looking, positive construct; it acknowledges a sub-optimal situation and implies you are now going to correct it.
> If I make an off-by-one error, where, other than me, did it come from?
I have seen countless instances, both in and out of software development, where a manager:
1. Explicitly told an employee to rush through a task too quickly, and that some bugs/cleanup/whatever would be OK and handled at a later time.
2. A short time later freaked out because the rushed task was not done perfectly.
Of course only terrible managers behave this way, but there are a lot of terrible managers out there. In these sorts of environments simple errors are often ubiquitous.
> If I make an off-by-one error, I could have done better.
"I did not do X, therefore I could have done X" seems clearly false. How do you know you could have done better? And if you could, why didn't you? And if you actually didn't, what does it usefully mean to say you "could have"?
You "could have" done better but didn't, does that imply you didn't want to do better? Is that what you want to communicate - you wanted your code to be worse - because that isn't in your favour either. You wanted to do better and didn't do better, that's back to implying you wanted to but weren't able to, i.e. you couldn't.
So answer the rest of my questions - you could have, you didn't. Why not? a) you actively wanted to produce bad code. b) you couldn't have. c) other?
> the Lord save us from those who have an excuse for everything.
Lord save us from people who think self-flagellation is at all useful or beneficial to anything. It's status-signalling and nothing else, you're in hypothetically the same situation as someone else (having made a mistake) but you want to claim to be superior because you're feeling the most bad about it?
In this post [1] we see you arguing that everyone makes mistakes, yet here you seem unable to recognize it as the obvious answer to your question. Perhaps not coincidentally, a failure to be semantically consistent is a common root cause of programming errors.
> So answer the rest of my questions - you could have, you didn't. Why not?
As a rule, I try to avoid responding to utter nonsense, though I must admit to breaking that rule in this thread.
That doesn't get around the fundamental problem here. Why did you make a mistake if you're arguing that you could have not made one? Either you didn't want to make zero mistakes, or you couldn't have made zero mistakes.
> yet here you seem unable to recognize it as the obvious answer to your question.
I'm the one who is insistent that it was a mistake and that people make mistakes. You're the one insisting there's some loophole where you can both get it wrong and feel good that you could have got it right, at the same time. I'm saying that it's your position which is utter nonsense, a meaningless double-think designed to make you feel good, which reflects nothing about the world.
Like a kid saying “I ate ten hot dogs and threw up, but I could have eaten fifteen!” - nobody believes it, you couldn’t, you’re trying to save face and get credit for eating fifteen hotdogs without actually doing it.
Now, whether you can do better in future is a different matter - I’m not saying you can’t do things to avoid that mistake happening again, or learn from experience, or get better.
> Why did you make a mistake if you're arguing that you could have not made one?
This is bizarre. Where on earth did you get the idea that I am arguing that one could have not made a mistake? The whole issue is about one's attitude and behavior after having done so.
I am not going to consider anything else you write here until you clear up that mystery, which seems to be the root of your confusion.
> About the only thing that annoys me at work is people trying to deny responsibility for their actions (or lack of them.)
Someone once said "There is a difference between 10 years of experience and 1 year of experience 10 times". The best developers I know always take responsibility and try to do better.
The point being made is how bugs invoke an automatic admission of guilt in developers, and absence of which shouldn't be seen as not taking responsibility, especially when tranches and layers in the system (built over the years, say) could have made the entire debugging and development process cumbersome, uneasy, unconventional, unyielding, dense, exhausting, and frustrating.
Taking responsibility might involve any among:
- documenting the behaviour for future maintainers.
- writing tests.
- identifying and pushing the management to fix technical debts.
- digging up the root-cause to fix deeper flaws, if any.
- advocating for saner development and deployment practices.
I earn a living from my SaaS. I am a solo founder, responsible for everything. I wrote all the code. My customers pay subscription fees because the software makes their work easier (it's a B2B SaaS, https://partsbox.com/).
Bugs are solely my responsibility: there is no one else to blame. And bugs mean that my customers paid money for a product which did not work as intended (certainly not as I intended it to work). I feel it is definitely right to apologize for bugs!
I disagree with the author: if I worked at a workshop and dropped a hammer onto my customer's foot, I should apologize. No matter what the reason: I could be clumsy, or you could say that no one could be expected to never drop a tool — still, an apology is in order, because I did drop that hammer, and it made my customer's day worse.
Therefore, I always apologize for bugs.
What I did, however, learn to do, and it is quite important, is not to apologize when you are not sorry. An example is when a customer is unhappy with the pricing, or complains about a missing feature. Many people will begin a reply with "I'm sorry, but…", and it's the wrong thing to do. I only say I'm sorry when I really am.
You write some code and a code reviewer points out that you used an API incorrectly, which you did because the documentation and test environments are out of sync with the production API. You will, of course, modify your code to use the API correctly, but will you "apologize"?
Now again, you call the API incorrectly, but your company doesn't do code reviews and they just ship the code. Your code ends up causing a lot of headache for everyone after it runs in production for a month doing the wrong things. Do you "apologize"?
Note, what you did is exactly the same in both scenerios. Should you apologize? Are you the only one who needs to apologize? Should everyone apologize? Like, do you all sit in a room together and go through a strange routine where everyone around the table takes turns saying "I'm sorry".
I'm surprised by all the disagreement over this post, so I wonder what people would think of these scenarios.
I'm not sure this was your intention, but you have just described how folks are supposed to do postmortem and retrospectives at most agile shops, as well as how Toyota created the kanban process and implemented the andon cord. It's strange and probably not useful if it's based around assigning guilt. But if it's based around trying to uncover a root cause in process or system deficiency and solving that, then no, it doesn't seem strange to me.
You can modify your code to use the API correctly, but if your team doesn't get the documentation fixed or the test environment to sync back up with the production API, your team is not solving the issue.
Your code can cause headache for everyone after runs in production for a month, but unless your team begins to do code review, you're not solving the issue.
In a very literal sense, the idea of the team finding an issue and resolving it (apology or not) is extremely important and one of the few ways for an organization to improve rather than decay over time. The apology is almost a formality.
Maybe I've been watching too many Star Trek reruns, but the thought comes to mind: "Blame is irrelevant, apologizing is irrelevant."
I've been part of such retrospectives, and no blame is given, and no apologies are given. There is no hesitation to lead the investigation into "your own code". "Your code" might end up being what needs to change, but it was not alone in causing the fault in the entire system.
Another though experiment (stripped of all moral judgement):
Alice writes some code which runs as part of a larger system for 10 years. No problems are identified in the system.
Bob writes some code. After Bob's code is integrated with the rest of the system, problems are identified in the system.
Changes are made to Alice's code which resolve the problems.
Who is at fault? You probably find it hard to identify who is at fault without knowing more details. You need details so you can form your own personal moral judgments. Perhaps a better question is: Can we ever objectively identify who is at fault? And does it matter?
This is a great question. To me, the only answer is (as I believe you're alluding to) "who" is at fault is not relevant when compared to "what" is at fault. In this case, the problem is the lack of proper systems level integration testing, and neither Alice's nor Bob's code in isolation, and the "who" that ends up being at fault should be the management chain of command that allowed the state of things to allow such a scenario to occur. As management decides to want to prevent such embarrassing and costly blunders, they should resolve to invest more in the process and tooling that prevents such situations from being possible.
Of course, it is also possible for management to shirk such responsibility and push that responsibility (without corresponding process ownership) onto the ICs. It's quite common in low performing organizations.
Why is apologizing (that is, accepting responsibility) for an error that you made--in either case, it's an error that you made--such a problem? This seems to come from a place of deep insecurity.
Alice and Bob are dating and plan to get married. They play a game in which they receive rewards for having the same answer to questions about their relationship.
They are asked: "Would it be preferable to serve ice-cream cake, or traditional cake at your wedding?"
Alice writes "ice-cream cake" secretly on her answer card, but Bob is still thinking.
After some thought, Bob writes "traditional cake" secretly on his answer card.
Both answer cards are revealed. The answer do not match, so the couple does not win a prize.
Alice criticizes Bob, "you should have known this, we love ice-cream, we had ice-cream on our first date!"
Bob believes he is not at fault. They argue. At one point Alice says "stop tying your identity to that question, just admit you made a mistake".
Bob still believes he is not at fault, and that he made no mistake, because it was never within his power to be certain what Alice had written on her card.
---
And now I ask: Is it within your power to be certain how the hardware and software of a modern computer will act?
My point is I will never be able to be certain that my code is bug free. That will never be within my power. I can only ensure that I follow a process that gives a good-enough probability that my code works correctly. What that process is, and what "good-enough" means, is largely determined by my company and team. I do follow that process, I do what is within my power. Should I apologize for not doing what was never within my power? Should Bob apologize for not doing what was never within his power?
I do accept the responsibility of ensuring "my code" (however the company wants to define it) is working well with the rest of the system now and in the future. Apologizing is completely orthogonal to accepting responsibility. Apologizing alone is not enough to "accept responsibility", and one can accept responsibility without apologizing.
PS - Alice and Bob eventually learned to avoid making moral judgments immediately in every situation.
Cognitive Behavioural Therapist (CBT) Dr David Burns has moved away from saying "sorry" to patients and clients who are upset by something during therapy sessions; he says apologising with "sorry" is such a problem because it's a too-easy meaningless platitude that people throw out without any thought and expect it to act to immediately silence the other person's upset without any further discussion, and the person on the receiving end of "sorry" knows this common use and expects it to be a cheap dismissive silencer which they can't respond to, so apologising isn't the same as accepting responsibility, apologising without accepting responsibility is dismissive and trivialising, accepting responsibility is better without it. That apologising doesn't add to understanding, it takes away from it.
Accepting responsibility is understanding the other person's reasons for hurting, which means listening to them.
Apologising is trying to make the other person to stop hurting, and stop them from talking anymore so you don't have to hear more or spend more time on it.
> You write some code and a code reviewer points out that you used an API incorrectly, which you did because the documentation is out of sync with the actual API. You will, of course, fix the mistake, but will you "apologize"?
If it was feasible for me to catch the erroneous API behavior through testing, before code review, I would see no reason to not apologize.
Your second scenario is not even remotely ambiguous, of course I'd apologize if I caused other people that much hassle.
It's always feasible to find a bug by testing. Even in the case where your code relies on some accidentally convenient behavior that might disappear in the next version of the API, you could have reimplemented the API as a stub in your test from only the documented interface. But it's often more efficient to find bugs through code review.
This thought experiment is flawed. It assumes the only variable worth considering are the actions of the individual. The reality is that we apologize all the time for doing something that, done one day previously or to a different person, would not have been a problem at all.
We're typically not apologizing for the act itself, we're apologizing for the effect it had. We don't mean "sorry for writing code with bugs in it", for example. We mean "sorry the bugs in the code caused you problems."
The though experiment illustrates that the same actions in different circumstances can have different results. What part of that assumes the only variable worth considering are the actions of the individual? The central point is that, as you say, whether or not we apologize depends on the circumstances.
I agree that you have to consider more than only the actions of the individual. I believe, if there is fault, it lies with not just one person, but also the circumstances. In cases where the circumstances are determined by management, company culture, legacy code, etc, the fault lies with many if not everyone. Thus, if one should apologize, then everyone should apologize.
Apologies for my misunderstanding (hah, very topical for the post). The way it concluded made me interpret it as if you were trying to suggest that the person's actions were the same, and thus the scenarios were the same.
Hmm. I guess I kind of did mean that. Rather, I meant to make people question whether the individuals actions were all that mattered.
Another example: If my wife wants me to invest in stocks and I do so after doing a lot of research and preparation, and that stock goes down, do I apologize? Do I apologize because of things that happen after and independent of my original actions? Or maybe my wife should apologize? Maybe nobody should apologize? How much depends on the stock market? Out of our control and comprehension.
With web APIs there are also a lot of things that happen, even when the API is used correctly.
The HTTP request can time out. The firewall of the user has blocked the request. The server might be turned of for maintenance. The server might have an expired certificate.
So sure, bugs happen, regardless of how good you are.
But there really are some people who constantly make mistakes, and those that rarely do.
There are people on my team where, when there is a bug, I just start looking at diffs of what they have committed because more likely than not, they caused the problem.
I think it's important to reinforce an attitude of trying to become better and people who give a shit when they make mistakes tend to also be the ones who make less of them.
> There are people on my team where, when there is a bug, I just start looking at diffs of what they have committed because more likely than not, they caused the problem.
If you can tell the bug from looking at diffs, why was the bug not caught in code review or by tests? Most obvious bugs should be caught this way.
In my experience, it's because Thing 1 and Thing 2 can review each others' code, and have no compunctions about potential bugginess. Somebody else gets to pick up after both of them, and is always outvoted during team code review.
Code review also isn't great at catching the kinds of edge cases that lead to many production bugs. Even tests only help you so much, because if you forget about input X or state Y or api result Z while writing the code, you're likely to forget about it when writing tests too. This is why bugs are more or less inevitable in systems beyond a certain level of complexity that are being actively worked on, and why engineers who think very carefully about anything that could go wrong will produce far fewer bugs than sloppy engineers who try to use process as a safety net.
> Through this lens, apologizing for bugs may seem innocuous. But it contributes to a bunch of cultural anti-patterns:
> * 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.
Imagine writing this. Imagine actually sitting down at your keyboard and writing down that people should not be striving to write bug-free code.
The article sounds much worse if replace "bug in code" with "made a mistake at work". Imagine if we're talking about a civil engineer, an electrician, or a doctor.
I agree with you, it's outrageous. What an awful article. I get the point (you should have robust and multi-layered quality systems) but just the complete rejection of accountability is embarassing.
Doh, of course no programmer intentionally writes buggy code, yet there isn't a single programmer in the world who doesn't write buggy code (and everybody who claims to write 'bug-free code' is either very inexperienced or a goddam liar).
The point is to not have a "shame culture" for writing bugs, because they are normal part of the workflow. Instead focus on efficiently identifying and fixing bugs (efficient debugging is an important skill that's unfortunately often neglected).
Otherwise you end up with people writing overly defensive code, and get into a situation like the Stalin-era airplane designers who each made their own parts just a bit stronger then necessary because they feared ending up in Gulag or against the wall if it was "their part" that broke. End result was planes that were so much more heavier than planned that they were essentially useless for the tasks they were designed for.
Of course we have to accept that bugs will be written. But that doesn't mean we shouldn't feel bad about writing bugs! Feeling bad is an excellent motivator to write fewer bugs!
John Carmack put this better than i can [1]:
> Left to themselves, most people have a tremendous ability to ignore their flaws, and it hampers their growth. A bit of shame is often a positive motivation. I am ashamed of a lot of code I wrote last year. I have reasons why it is the way it is, some of which are defensible, but some are just “WTF was I thinking?” If you don’t have nagging bits of guilt about your recent body of work, it might well be a benefit for someone to point out problems in terms that break through your defenses.
I wouldn't call it "feeling bad", but "feeling responsible" for your own bugs. No finger pointing and blame games, just sit down and fix your own bugs, try to not run into the same problem next time, and inform your team mates about what the reason for the bug was and how the fix looks like.
But there's no need for a "formal apology" to your team either. The user might deserve an apology by the PR department, but this shouldn't single out the actual developer who wrote the bug.
To commenters who compare work of programmer with the work of civil engineer:
There is an explanation to this discrepancy. Risk = probability of fault * cost of fault. Programmers usually work with the data. Data has a pretty very unique property that it is easily and cheaply copied and restored. It also means data can be replicated more easily, which allows to build systems with large amount of redundancy. Therefore, price of a software bug is usually orders of magnitude less than the price of breaking something in the physical world. This allows to drive up probability of fault parameter and allows for much faster evolution and less regulation.
I think a part that needs to be considered in the comparison is also the concept of safety factors.
Many structural engineering projects are built with a safety factor greater than 1, which allows for - as you'd imagine - safety. In software, it could absolutely be done that every function has explicit validation checks for each input, and that more safety, error handling, and checking is written. The economics just don't make that viable though except in the most extreme situations where this is required. In aerospace, with the exception of the recent Boeing debacle, there's been very few software related issues (that I know of) relative to the number of CPU cycles run and flights taken - I'd be willing to be there's far more mechanical issues that cause grounding and maintenance cycles.
Now look at civil engineering and infrastructure. How many roads do we drive over daily filled with potholes? How many bridges get patches and repairs every few years because of concrete cracking and rebar rusting? (I live in Quebec, so there may be bias in this statement). Maintenance like this is just paying down tech-debt - the same as in any field.
Software absolutely can be built to a high level of robustness (and it is) - it's just not economically sensible in most cases.
Replication costs have nothing to do with anything here.
The damage caused by a software bug can range from nil (even negative, since a bug might have desirable effects) to incalculable. Consider a bug in software used for landing SpaceX boosters... Or a bug in a trading platform. Or a bug in an automated medicine dispenser. Or...
You can compare the work of a programmer to the work of a civil engineer, but it's true that it's difficult because most bugs cost little, much software is not positioned to cause much damage if buggy, software bugs are so prevalent, and it's so difficult to write bug-free code. But the cost of replication of software has nothing to do with any of this.
> Replication costs have nothing to do with anything here.
Replication is the cornerstone of fault-tolerance. When logic is written in high-level languages with some minimal good practices, most SW bugs result in crashes rather than data corruption, hence data replication plays important role in protection against bugs as well as HW problems.
> Consider a bug in software used for landing SpaceX boosters... Or a bug in a trading platform. Or a bug in an automated medicine dispense
I specifically mentioned: "Programmers _usually_ work with the data. <...>" In the examples you listed above software manipulates physical world rather than pure data. I thought it was too obvious to explain.
Would you be ok with your dentist being OK with her slip-ups?
“I really should have checked the x-ray better before I extracted your front tooth. But you know, I’m not sorry. It was an external constraint — there was a queue of patients waiting”.
I can’t believe how low we let this profession sink. I hope in 15 years we will look at thies era like we look at the Wild West today. Exciting from a distance but nobody would really like to live like that.
In some countries at least engineering is a professional title and properly gated, but until we stop allowing people to call themselves engineers after a six week bootcamp in websites design this downpath will keep going on.
Like on that dentist's case, my hope is that as liability persecutions and lawsuits due to faulty software increase, that will eventually be sorted out.
What I think should be common in these two cases is the attitude of a professional towards their work.
Building software should be an engineering discipline with all its perks and responsibilities just like building bridges. We rarely see it and it propagates to the craftsmen who seriously believe that good quality software is impossible to write under the slightest of constraints. Like business pressure.
We had this ability in the past when programming was way more difficult, tedious and error prone. Look what IBM did with their “Clean Room” approach.
I’m sure we still have it at many places but we choose to spread the myth that it cannot be done. This call to stop apologizing is the next step towards not even trying.
> What I think should be common in these two cases is the attitude of a professional towards their work.
I think everyone would not deny this fact. Engineering is more of a discipline.
But if you see things practically, this issue of "bad" code may not happen for various number of cases. For example, unclear project requirements, use cases etc., That is where 'context' of what happened helps to better understand the situation.
Building bridges are not done agile and it has a learnings from decades or even centuries. Computer Engineering is mostly agile where you push changes based on changing requirements.
This reads a bit like one of those feel-good "managers should be good to employees! agree?" posts on linkedin. The bugs I see in PRs from even some mature people are things like input_array[0] without checking the array for null or size. Anyone beyond cs101 can tell you this is unacceptable and careless, and the author likely had a "fuck it" attitude, and was in a hurry to get back to Netflix or whatever was really on their mind.
Should we expect for them to go into a full-on dogeza Japanese kneeling bow apology? Of course not. But there are many cases where a person glaringly half-assed something, cut corners, quietly committed something directly to master. And yes, this person should feel some kind of regret, or should be brought to stop such behavior because it is extremely destructive and is totally avoidable and caused not by overworking or accident but by persistent carelessness and neglect, so it cannot just be cheerfully swept under the rug.
Why doesn't your team have a process (integration tests, etc) that makes it impossible to check in something like `input_array[0]` without breaking a build? Why is it allowed to directly push to master?
How does the old saying go? The road to where is paved with good intentions? You could engage in moralizing against "carelessness" and "neglect" and presuming that a teammate somehow cares more about watching Netflix than doing their job (which they presumably outperformed other candidates to even get), and maybe that will make you feel better. You are the good, careful, model employee, and that other one -- they're careless, slovenly, apathetic and lazy. But if that's the case, how did they get past the door in the interview process? If the whole company is like that, why do you work there as opposed to a company where the bar is higher? Something does not add up. In all likelihood, your explanation is a rationalization and not the most obvious answer, which is that your process could be improved but it hasn't been because such investments are not viewed by your companies executives as improving the long term bottom line to be worth the short term investment cost.
Take a look at history and figure out how companies in the industry have solved this problem before by building more bulletproof runbooks, processes and tools. These companies, as they approach enormous scale, necessarily have to determine how to deal with employee reversion to mean. It turns out, surprisingly, that process eats good intentions and care for breakfast. You'd be surprised at how quickly those good intentions become useless if your company is successful and you hit hypergrowth and scale. It's ironic that for a profession where it is so tractable to automate away mundane or repetitive tasks, where we study spacetime complexity in data structures and algorithms, that we have so many practitioners that default to witch hunting and moralizing and seem unable to apply spacetime complexity or procedural analysis to their own software development lifecycle. I expect to see this trend change as our still young industry continues to mature.
Because we were a 4-person company at the time starting to hire first employees and I realized I can't trust new people as much, so most certainly you cannot anymore do things like input_array[0] and committing to master because i took measures immediately after it happened, so that is not a problem.
The problem is that the person(s) for whom I had to add these baby bumpers not to do input_array[0] will - and has - screwed up much bigger on everything that is slightly more complicated than that, too. Because if you are an engineer and you don't care, then no amount of padding around you will make you curious, careful, detail-oriented, non-lazy and capable of tackling hard problems that life throws at you every day at a tiny startup.
Shipping with bugs is not an inevitability. Bugs come from code being used in cases other than the ones that the programmer anticipated. But it is possible to understand how code will be used. You can test against it, either manually or with some automated testing tool. And you can produce code that behaves the way you expect it to every time you run it. Every once and a while you might mistype >= as <=, but you can catch it and fix it with only a modicum of effort.
But you first need to believe it is in your own power to write less buggy code. If you can identify patterns that frequently produce bugs, you can try to avoid them (e.g. copying & pasting: very buggy!). You can identify, isolate, and document footguns and complex API. And you can be proactive in simplifying systems when feasible to do so.
Don't beat yourself up if you accidentally have a bad commit, but don't excuse sloppy behavior. Demand better from yourself. Don't produce garbage software.
This sentiment reminds me of Gerald Weinberg's observation of four plus decades ago - "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." I was trained as a computer engineer, and the difference between those who were taught to approach software development as a craft and those who think bugs are ok and it's really about feeling good about myself at the end of the day is clear and obvious in most organizations and in the product that comes out of them.
At the same time, if programmers had to deal with the same kinds of rigid constraints as builders, writing a simple MVP would cost millions, and we'd have a lot less new technology in the world.
Every once in a while a barrista is going to forget to you wanted soy in your triple venti no-foam soy latte instead of whole milk. They're serving a thousand drinks a day and the impact of getting the order wrong is tiny.
They're still going to apologize to the customer who got the wrong drink. Because sometimes mistakes are acceptable, expected on occassion, and still worth apologizing for when they happen. I don't always say sorry when I do something wrong, I sometimes say sorry when what I've done has a bad impact on someone.
On the other hand, I (and probably a good amount of other people) say thanks after getting our coffee, but I think it would be pretty ridiculous to expect to be thanked for every feature I create.
All I can add is that, as a freelancer, I always explain (like they are 5) what went wrong. My customers don't care about the details but they like it when they know I made an effort of creating good software (bugs included).
As a manager, I've always striven to apologize for my errors.
I do agree that errors are unavoidable and are bound to happen. That's why I actually never cared at all whether programmers apologize for bugs. Fixing bugs is also part of the software development process after all.
However, I've always believed an apology is important to show humility to my team mates. As a manager, I do not want to appear entitled. Of course, as soon as the error is uncovered, we should prioritize it and fix it. But I do not believe that proceeding to fixing an error is orthogonal to apologizing for it.
We are trying our best to build a company without a guilt culture. In such a position, is apologizing a bad move as a leader? What would you do?
I'm a manager and I appoligize if it was a stupid mistake made from carelessnes. Apologize if you did something you wouldn't want other people doing.
I think context matters too. The industry you're in (what are the consequences of bugs) as well as the part of the codebase (presentation or data integrity) change the acceptability of bugs.
If you fuck up I don't really care about an apology. I want to know:
1. How will you fix it?
2. How will you prevent it from happening again?
An apology, in my head atleast, is for when you have caused emotional distress to someone and there isn't much you can physically do to fix it other than to convey how you now feel about what you have done. When you make a practical mistake an apology is implied by you fixing it.
There are perhaps two parts to an apology. One is an acknowledgement that you did something wrong, and that you should not have done it. The other is a sort of ritualistic, performative (in the original sense!) use of language that may make someone feel better. This is the difference between:
"I made a mistake when i dereferenced that null pointer"
and:
"I'm sorry i dereferenced that null pointer"
I absolutely agree with you that the ritualistic part is pointless, and perhaps harmful if it is performed instead of actually fixing the problem (see also "thoughts and prayers").
But i wouldn't want to stop doing the acknowledgement part.
I wouldn’t refer to the first stage as an apology, it is simply an acknowledgement.
I very rarely apologize for a bug at work. I don’t expect others to apologize to me either. Apologies should be reserved for personal/relationship things, like forgetting to invite somebody to a meeting.
Probably 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.
Understood. 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
Indeed, 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.
One 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.
I'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.
But 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.
I 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?
I am in complete disagreement with this sentiment!
If you're using my code and hit a bug, I am, genuinely, sorry. The goal state is craft software that works properly. That is not an unreasonable goal!
Of course, mistakes will happen, but you should be sorry, and you should think about what would have avoided it (better programming methodology? better testing?).
Aim to create high-quality software that delights its users!
I'm not like on my knees begging for forgiveness, but I feel regret that an unfortunate thing happened.
To me it's a similar situation to if I, say, accidentally spilled your drink; something of that nature.
(I guess different people could attach different amounts of significance to the word. To me it simply means, "I feel sympathy that this unfortunate thing happened, and I wish it had not.")
Bugs are the responsibility of the process that brought them there. In most cases it is shared responsibility.
Why doesn't your dentist mess up 1 out of 5 interventions? They have gone through years of strict training and there are giant liabilities in place.
In development? A lot of self-taught developers, who can always jump to a next gig because of never-ending demand. This sets up the scene for a totally different scenario - never-ending stream of bugs.
If you want your team to have less bugs, then as a manager make sure you have a process in place that optimizes for that. Start with your hiring process and add requirements for code quality practices. Then build a process that includes strict commit guidelines, documentation, code reviews and QA process. Most importantly, add time to estimates that ensures all of the above is checked properly. After all that is in place, define in a clear way some sort of liability for bugs.
Your dentist goes through all of that, why not your developers doing arguably equally important work?
I believe the answer to your question of why developers don't generally treat quality the way dentists do is one of economics.
The world needs enough software, and the world's requirements for quality are low enough, and the average developer writes reliable-enough code, that in most cases money can be made without special attention to quality.
In some domains, quality is paramount. I imagine that quality and bug mitigation are the primary concerns of someone who manages, say, an X-ray machine firmware project, or avionics software. Software for these purposes that is not extremely reliable cannot compete in that market. For other kinds of software people are paid to write -- like social networks for pets -- reliability is a much lower priority.
Certain kinds of software needs to be rewritten constantly to meet the demands of highly-evolving markets. Games are an example of this. Reliability is important, but not paramount, because the underlying business can only continue to compete by at some point stopping work on the reliability of existing games, and moving on to developing new games.
I'm sympathetic to the respect you have for the value of high quality software. But the reality is, the value of quality varies dramatically within the software industry -- much more than it does within, say, dentistry, or medicine, or aviation.
Fewer bugs isn't necessarily the primary concern of those using and buying any particular kind of software.
Are there 100% medical procedures with 100% success rate?
To me it seems that failures happens pretty often, generally due to incompetence, limitations in the science regarding the problem or insufficient resources. Seems very similar to bugs to me.
The question is how bad is failure, obviously if someone's health is at risk, you have a much bigger incentive to have processes on the safer side.
Maybe you feel "bugs" are more frequent in software because the software you're referring to has an incentive towards innovating rather than stability.
I'm sure if you studied software used in critical systems, the failure rate would be more in line with a procedure at a dentist. You can't justify the kind of cost that kind of development has for most apps.
May be - may be not. Would you trust your dental work to a self-taught dentist? What makes developers a special case? I am agnostic to it and genuinely curious.
But I disagree about it being something special to leaders.
And the way he says it, makes it sound like maybe he thinks leaders shouldn't apologize in general. Which I think is a fairly common belief that leaders use to justify not admitting they made a mistake. And is 100% different from not apologizing for bugs. Since as he points out, bugs are not mistakes, they are a normal part of development.
When the manager makes a significant mistake it's not like a bug, it's a poor judgement that probably affected everyone. And sometimes if it's a very negative affect then an apology is warranted. But at least, it's usually necessary to acknowledge when you had people going in the wrong direction.
I think it's worth acknowledging over your customers that the bug has caused them lost time or other kinds of issues. Whether you do that with an apology, it doesn't really matter, but I know I'd personally feel better when a vendor emphasizes with me.
Something you definitely don't want is to sound like it's an inconvenience for you that they're reporting bugs. Bug reports are extremely helpful and you should be grateful that they're taking the time to report them to you.
It's interesting how polarizing this article is. After zigzagging several times while reading the comments I just think that reality is more nuanced than "never apologize" or "apologize", and it simply depends on the context.
It seems to me that most comments with a strong opinion (including the article) have a specific scenario in mind, involving assumptions about the dev's intentions to write good code, the bug's effect, how easy it would have been to avoid the bug, and who is this person we're considering to apologize to (coworker / manager / customer / QA who found the bug). In some situations apologizing feels right, in others it doesn't, so there's not much sense in generalizing from a single scenario to the general case.
I think ultimately it comes down to matching expectations: almost all people involved in software development expect bugs. The question is how much effort do they expect me to put into reducing the quantity and severeness of those bugs. When I go to a dentist I expect them to make every possible effort to avoid harming me; generally this is not the expectation of software developers going about their day. A feature that takes one hour with reasonable effort at ensuring quality could easily take a day or a week if you make _every possible effort_ to ensure it is bug-free. Different pieces of code (at different times) could have different amounts of impact, so it takes a wider understanding of the code's context to decide how much effort I'm going to put into chasing bugs. When in doubt, I match expectations with the relevant stakeholder(s). Then the situations where apologizing feels right are either those where I didn't meet the expectations, e.g. I was in a hurry to push so I didn't take the time to properly test and I should have known better (not very frequent); or situations where I didn't take the time to properly match expectations (though sometimes that's on the other party, but it takes two to match expectations).
One other thing regarding responsibility - I think that taking responsibility and apologizing are different things. Sure, you can take responsibility by apologizing, but there are other ways too. When something breaks in my apartment and I call my landlord, they (usually) take full responsibility and make sure the problem is fixed, but so far they never apologized, and it would feel funny if they did.
A lot of the replies and analogies here are interpreting this as a business-consumer apology. Of course if a business has disrupted a customer's experience through buggy software they should issue post-mortem/apologies/etc.
But I read this as though the author is saying apologies to fellow teammates shouldn't be necessary, which I do at least in part agree with.
I wish I could find that one guy I worked with about 19 years ago that tried to load an ActiveX component in his VbScript running in Netscape and send him this article, true he never apologized - but I just want to make sure he doesn't feel bad about never apologizing.
Bugs categories are also important. My project and my leadership was destroyed when a non-technical wanna-be "operation" manager without experience in software development, started to see only bugs and reduce all development to bug fixing. Some "bugs" are in reality wrong or misunderstood requirements. Some are missing features. Sometimes the joke "it's not a bug it's a feature" is real. Sometimes "bugs" are edge case we didn't want to solve immediately, until the edge case it's not edge anymore.
I think what is dangerous it's seeing ONLY bugs, focus dev ONLY on bugs. Shift a little the point of view from bug fixing to software evolution.
Maybe as a Canadian we've eroded the stigma with apologizing. Saying you're sorry is not about taking blame or responsibility; this attitude is what stops an overly litigious society from saying "sorry".
It's an empathetic response that says "I am putting myself in a different context and trying to understand how it feels". This makes it perfectly appropriate to say "I am sorry" a lot more than we do: when learning about a friend's bad-luck circumstances, a customer's poor experience or adding a bug to your code.
This touchy-feely analytical approach to not worrying about emotional and exemplary damage resulting from not knowing any better is hard to take. The self importance of not worrying is conducive to the sloppy industry the NG works in. No one can be held responsible for not knowing what they should know because they aren't expected to know it. They are semi-functional components in a dysfunctional machine.
This seems to conflate ownership/responsibility with admitting a flaw in yourself.
If someone points out a bug, I say thank you. People make mistakes. I am a person. I make mistakes. This is not controversial, it is expected. We should still strive to avoid them and are allowed to be annoyed with ourselves when we make them, but it doesn't make us bad people.
The biggest career lesson that I've had is that 80% of development is testing.
Should you apologize for bugs? No. But if you're doing professional quality work, (as opposed to prototyping or researching,) a large portion of your time (as a developer) should be writing automated tests (like unit tests) to test the code you write.
Maybe don’t apologise for it, but I definitely think it’s useful to acknowledge if it was your code as it removes an awkwardness around it. Obviously this doesn’t have to be done for every little bug but if there’s a discussion around one then owning it can help.
While I agree with not "blaming" people for the mistake as if it's their fault as a person. I disagree with all of his reasoning and the action he choose not to do in this case.
I also take the position of "criticizing the idea/code, not the people" when it comes to other people's work. I rarely have a problem with criticizing myself.
Especially when it comes to "your" own code. You should be able to apologize for your mistake.
> It reinforces the idea that any one person or piece of code can be blamed for a given failure. Short of malice, this is never the case.
You can be attributed to your action. If you can be attributed to the good things in your work, then you can be attributed to bugs. Unless you are claiming that you have no control what so ever about how your code turns out, at which point, what are the different from you and a typewriter?
The thing is, you can be attributed for an instance of error. You can be blamed for the error you did. But you should never be categories as "the error".
> 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.
Yes. There are instances that I could have written it better.
> 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.
> 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.
I take the approach and culture of "be strict with yourself but be kind to others". When I talks about other people's bug I always criticize the bugs itself and talks about problem and process in general without tying it to them. But when I talked about my code, I will also express what I could have done better or what is the pros and cons of my coding decision.
The thing is there's different between people striving to better themselves, and people blaming others for not being better.
You should strive to be better, while at the same times not being a snob or looking down on other for not being perfect.
In every day's life there's no permanently good people or bad people. There's bad action that people do. You should still be able to attribute a certain instance of event to a person. You just don't have to hold grudge and judge them forever based on it.
I am probably reaching it here, but I feel that the author is the kind of person that can't take criticism of his idea well because he feel that his idea is himself.
Your idea and action is yours. But your idea and action is not who you are. If you think it is yourself, then you become blindly defensive and either never acknowledge that you did it, like the author did, or never change.
One is all-about-you. The other is a team-building action, recognizing the folks who normally get a lot of grief(denial; accusations; ignoring their input). Testers respond amazingly when they're heard and treated seriously.
It is so profound, let me tell you an anecdote. My test lead had gone to a conference (they have them!) He was in a bar at the end of the evening, shooting the breeze about all the type-A developers they have to deal with, with a group of attendees.
He told the group "I have a guy in my company, I find a bug, he thanks me! Then works closely to categorize and then fix it. No complaining; no yelling. He just says Thank You! and gets on with it. Says I saved him embarrassment if the bug had gone any further, and saved the company money."
Another guy in the group, from a different company in a different state, said "I know who you're talking about. I'll write his name on this napkin, you tell me if I'm right". He wrote my name and passed it over.
They had never met; never working the same companies at all. Were in different places in their careers.
But I had worked with both of them. One of them, 8 years before. But still, still I was the only developer either of them had ever dealt with, that responded positively to a bug report.
Think about it, and then go thank your tester.