The top answer has it exactly right. This should be Root Cause, since ultimately even bugs caused by human errors are really caused by systemic flaws. Some examples:

  * SQLite has 1177 times as many tests as code (not a typo)
  * Live television is broadcast with a 5-10 second delay
  * IMVU automatically reverts commits pushed to the site if regressions are detected
  * Netflix implemented a system called the Chaos Monkey, which randomly shuts 
    down processes. Ensures the system can survive any failure
  * VLC, Unity3D, Windows, 3D Studio Max and many more applications phone
    home crashes, which allows developers to quickly patch frequent issues
  * Code reviews and pair programming ensure no one person's mistake
    can break critical code sections
  * Similarly, multiple people should sign off on copy written. For newsletters
    and press releases the whole team should, since they can't be withdrawn
  * Well designed systems automatically backup, and those backups are 
    automatically tested, so nothing is deleted forever

Change "who" to "why" and a horrible idea turns into a brilliant one. Well designed systems can reduce the risk of almost any mistake, at the cost of speed and flexibility.

Ultimately it's up to the company to decide where the balance lies, and to live with the consequences. Startups will accept a drastically different risk profile to banks and Fortune 500 companies.

I'm usually arguing against stereotyping management around here, but I find it a stretch to believe a boss who thinks "Person to Blame" is going to be willing to pay the cost for true root cause analysis.

I have a feeling it's more like: <git annotate>; "Oh, it's Bob's fault."

We actually had a tradition at one of the places I worked at, where someone along the way brought in a trophy and the title was changed to something along the lines of best bug write. Anytime a bug broke the system the trophy was passed to the person that broke the system. It was actually light hearted and effective. We would make a big deal of passing the trophy, but no one wanted that trophy. It was not punitive, but more of a joke, kind of a simple reminder that I don't want to be the guy with the trophy on his desk.

I completely agree with that - the boss in the story sounds like a lost cause. My post was more of a speaking in general kind of thing.

I was going to go off on a tangent about the importance of good management, but I haven't ever had a boss (self employed then startups), so by missing half the picture I didn't really feel qualified.

If you tell me to blame someone every time there is an issue, and you don't let me find out why, I'm going to blame you. Because it's your fault as the boss of the department till you let us prove specifically otherwise. That's what responsibility is.

Changing who to why is brilliant. That encourages investigation and understanding of the problem.

+1 on "root cause" being the field rather than "person to blame".

"person to blame" pre-supposes that the root cause is a person, which is not true in most cases. While programmers do introduce bugs due to oversight, I have seen that systemic issues (build environment doesn't allow for tests to be written, missing patches in legacy architecture, bad staffing decisions etc...) introduce a large percentage of defects, especially in larger projects.

If your manager is really interested in reducing defect injection, you will want to champion root cause analysis (read up on it - Karl Wiegers and others have some some great work on this).

While the why is important the who is important as well. In any organization of sufficient size there are going to be B grade developers, or even just young developers. It is important to understand if certain people are writing most of the major bugs. Now there might be a good reason for it such as the difficulty of certain pieces of the application, so bug density is not the only thing to look at. However knowing who is writing bugs that cause outages is very important for proper accountability.

yes, who wrote the bug

...and who reviewed the bad design

...and who reviewed the bad code

...and who wrote the bad tests

...and who built the spaghetti system that can't isolate failures

...and who pushed new code to production without smoke-testing

...and who demanded the product ship before it was ready

    * Well designed systems automatically backup, and those backups
      are automatically tested, so nothing is deleted forever

How much software automatically backs itself up? I'm solving this problem with my startup, http://www.restbackup.com/ . I provide online backups that software makers can bundle and sell to users.

Joel Spolsky refused to add a "blame" field to FogBugz for years, he used this as an example of how you should not give the customers every feature they demand, and he said it was one of the top most requested features. He explained that once you add that field it will be the end of fixing bugs and making honest bug reports. Developers will work with QA so that bugs don't get entered into the system. Long arguments will ensue about whose fault a bug really is, and massive time will be wasted on this. One of the jobs of a software designer is to construct a tool that encourages good ways of working and not dysfunctional ones. New features need to be evaluated with this in mind.

Eventually though after he turned over project management of the software to the employees, they responded to the constant bug reports about the lack of this feature and added the ability to have this field. I recall he made a note about it on his blog, but that the project belonged to them and it wasn't his project to micromanage, so now they have the feature whether he likes it or not.

Caution: I probably have half the details wrong, I'll try to find some links.

Update: http://www.joelonsoftware.com/news/20020912.html

Aaah... if only Open Source developers learnt from that Joel's article from 10 years ago!

Instead, filing a bug for Firefox, Gnome or the majority of popular open source projects requires you to provide even the color of your socks.

One tradition I really appreciate at Google is the post-mortem. Any serious outage or bug will be followed by a detailed post-mortem detailing a timeline of what went wrong and why.

Sometimes this will go as far as establishing a "war room", possibly for weeks, dragging in people from a number of different areas to address a particular issue.

It's not about pointing the finger or otherwise apportioning blame. It's about learning from mistakes and preventing them from happening again.

That being said, I've worked at other places where shame is attempted to be used in such situations (which is what this is). In my experience it just fosters a hostile environment.

At a prior job I was a key member of a team that did a 2 week long, intense root cause analysis of a prod issue that threatened a multi million dollar contract. I consider it one of the most interesting and rewarding things I've done in my career. All obstacles were removed, we could follow the clues wherever they took us, use any resources etc. In the end it took careful analysis, many simulations and hard work to find and fix the root cause, and no fingers were pointed, instead we learned some good lessons and were better for it.

When done right, RCA is a great thing.

A good programmer will feel shame from that whole process even if nobody points the finger at them. The blame game just isn't needed.

A bad programmer shouldn't work there in the first place, and if they need to be blamed, they're probably doing other things to destroy morale.

If we stay in common sense ranges, a bug is not something you have to shame or proud. It is just part of the working process.

s/programmer/worker

I find it interesting that you'd feel shame over a bug. Why?

I feel shame over bugs. Of course, it depends on the nature of the bug, but there are definite moments of deep self reflection, which I think that I internalize as shame. While I reflect and move on, as a professional, I should be making as few mistakes as possible. When a star hockey player screws up a play that could have won their team the game, I imagine that they feel shame - not that they will get fired for the incident, but self relection is how you improve, and in many people, that manifests as a healthy amount of shame. (Not that I'm the Gretzky of software development).

Recently, a piece of code that I wrote crashed after running for over a month because I forgot to lock one of several methods that was concurrently accessing a collection. I was very ashamed of this - this was an amateur mistake, and one that someone with the amount of experience that I had should not have made. I didn't get any any trouble for this, but I was pretty ashamed. "I am better than this, and I should not be making this sort of mistake," I thought and have been very careful to avoid this sort of thing since.

I'm not dogging people who feel bad over bugs, I just don't feel that way myself. I've never written a bug-free piece of software, so I just accept that bugs are part of the deal. When I screw up, I just fix it. On the bad ones, I feel a tinge of regret (as in "oops, my bad. Let me help correct that.") if I inconvenienced anyone else, but nothing I would call shame (which to me implies internalizing negative emotions about one's self).

I don't write perfect software, and I never will. I'm choosing to not feel bad about that. It's all matter of perspective and expectations, isn't it? My colleagues can think less of me if they like - that's their baggage, though, and I won't pick it up. Shame is dangerous, and leads to a lot of the communications errors that developers make, which are often worse than the bug itself, or even the cause of it.

This is a very well-known phenomena. If you don't feel anything after a bug in your code cost your company lots of money and your team members many days in debugging and fixing it... then you're like nobody I've ever worked with.

Really? My first major software release took the AOL mail system down for 34 hours. My later work kept it up for 8 years. I consider both equal fodder for bragging, self-immolation, and war stories over drinks. I couldn't tell you which taught me more.

That sounds like you feel something about both of those things.

I think what the previous commenters are trying to say is that you shouldn't be OK with producing lots of bugs. Sure, you can learn a lot when you make a mistake, but you shouldn't be making the same mistakes.

I think the bragging part of the bug that brings the system down for hours and requires significant efforts in RCA is that the initial work was important and the bug likely to be non-trivial. Non-trivial bugs happen. I will not be proud of small stupid bugs I make but non-trivial bugs, the discovery of which brings sort-of an excitement - that is something I can be proud of.

You're right. I feel sheepish and proud and part of a bigger effort, but I do not feel nothing.

That sort of sounds like how Morbidity and Mortality conferences at hospitals are supposed to work. It isn't about assigning blame(unless someone really screwed up) but examining the mistake in front of the whole department so that everybody learns from it.

Right. Ideally, everyone is willing to take responsibility for the work they do and are proud of it even when it contains flaws.

If you can't handle having bugs in your code without getting all defensive, you probably shouldn't be coding. The only way to get better is to get feedback.

My company, LiveOps, does the same thing. Every customer impacting issue gets a post-mortem, and some non-customer impacting problems get one.

We have good stability (we hit four 9s recently), but we're always pushing for me. The post-mortem process is very positive and affirming. That's because it's transparent, as it should be.

Interesting. That reminded me of this book "Start-up Nation: The Story of Israel's Economic Miracle" which says their military runs the same procedure in a similar way after missions.

As an Israeli, I can vouch for the massive ass-covering that goes on there. In fact, we just had a big public ass-covering demonstration regarding the awful flotilla blockade. Regardless of what one thinks of the political aspects and/or morality of that action, the purpose was to examine why were several soldiers injured and Israel's relationship with Turkey, previously a strategic ally, deteriorated. Both these results were seen as failures of the mission. The ass covering was plain for all to see, on the national news. I agree that the Israeli army has a very substantial contribution to the high level of entrepreneurship and technological achievement in the country, but effective organizational behavior is definitely not something you want to pick up from the IDF.

> effective organizational behavior is definitely not something you want to pick up from the IDF.

(1) The IDF is "ineffective" on an absolute scale. (2) The IDF is significantly more effective than most other organizations.

While better isn't perfect, you can learn from both.

It's also a lot easier for large organizations to examine issues of a less sensitive nature. AKA missile detonates in the middle of a field vs school.

Why do you claim that the IDF is more effective than other organizations?

http://www.globalfirepower.com/ Compare that list to the population size of each country, Israel is a very large outlier.

National will is important, but you don't rank on that list by being ineffective.

> Why do you claim that the IDF is more effective than other organizations?

I didn't claim that the IDF was more effective than all organizations, I said that it was more effective than most.

For example, I'd claim that the IDF is more effective than almost every failed startup.... (You can argue that many fail for reasons outside their control, but I'll respond that such vulnerabilities are a failure.)

Almost all armies do this, and they do it really, really well.

As a veteran I can tell you that everything you do is critiqued, and everything your boss does is critiqued, and so on.

At certain levels it's peer review, at others, hierarchtical. The whole point of it all is to increase your chances of survival.

It's a great process, and I've noticed that most military folk are great at speaking plainly and accepting critique, much more so than civilians. I beleive these processes are a huge part of the reason.

I don't know... maybe it's where I work, but the post-mortems I've been to all too often mandate some useless extra layer of review or process on top of an already byzantine change control scheme. Sometimes, "shit happens", and I wish our availability teams appreciated that.

And even if there is justification for additional process, they should let the ops/dev teams come up with ideas/solutions themselves: we know our tools and teams best.

I was a senior manager in an organization where one of my peers essentially inserted a similar blame regime into our incident management process. It is a poisonous practice, but I actually loved my job and wanted to improve the place. So my team fought back.

The way that you defeat a system like this is to use it. Be humble, honest and calm, and go out of your way take the hits. But refuse to be blamed for things that aren't your responsibility. Force the problem people to do the same.

That undermines the system, as your putting the problem person in the uncomfortable position of taking responsibility for his actions. The whole point of "blame assignment" is to deflect blame from the golden children.

In my case, the blame regime lasted a few months. It collapses when the person pushing the regime is on the defensive too often.

That doesn't work when you have somebody like me who would never accept blame if it was to be written in a permanent file, because I know it would end up being used to fuel some KPI.

And in development there is always somebody else to blame if you look hard enough (because every time a choice is made, it has costs).

Sure, you can spend your time looking for ways to blame other people. Or, you could just go back to getting stuff done.

I do -- because I work in a shop that values getting stuff done.

But if you work in a shop that values covering you ass, then you should cover you ass and not care too much about getting stuff done (and then make a plan to get out of there).

This is so much better advice than "fight the system", "convince your boss", "use these talking points", etc.

If the poster really wants to keep that particular job, but wants to also improve the environment, they need to start following all of the rules they don't agree with to the letter. The worst thing that can happen is that it actually improves the team somehow.

It's not always the right way to make change, but in these situations it really can be the best route. Bad rules and procedures can only be (officially) recognized as such when they're actually being used. There's no need to make a mockery of this stuff, either, because time will tell whether the new rule is really helping or hurting.

Like you say, humble, honest, and calm.

The more blame you try to place the fewer commits you're going to get (and the ones you do get will be larger and full of "defensive code"). Less commits, less often will make the problem worse, not better because the merges will be larger and more painful, and more subtle systemic errors will become the norm.

This is one of those solutions that causes more of the problem its trying to solve. Management will love it.

I came here to write a comment- and happened to click the OP link and saw that Doc Brown and I think alike.

Reminds me of a consulting story.

I was sitting down with a team getting started on Agile/Lean, and I was trying to lighten things up.

"Well, the first thing to do is pick somebody to blame when it all goes south," I paused for effect, "and that's usually me, the consultant."

It was dead silent. Everyone in the room was looking at me seriously.

Tough crowd.

I had a new PM come in and give a similar speech. "If we fail spectacularly, it is going to be my job. But if we just fail, it is also going to be my job. More importantly, in neither case is it going to be your job. So now is the time when you can do spectacular things in utter safety; I'm asking you to take this opportunity and run with it!"

Warren Buffett practices, "praise by name, criticize by category." This is the opposite.

The way I've heard that principle phrased is "praise in public, criticize in private."

It's good advice, because criticizing people in public (i.e. in front of their peers) always backfires -- it just makes the criticized person defensive, so they stop being open to learning from their mistake.

We have such field in JIRA too. At first it wasn't required, so nobody filled it. So it was made required by upper management.

People filled it mostly with our boss (we agreed with him, that when it's hard to say whose bug it's - we assign it to him), or old workers, that work here no longer, that first made commits to the feature where bug is. Or people solving the bug assigned it to themselves. Only sometimes somebody assigned a bug to another programmer who still works here.

Now the field is optional again.

I wish bug trackers were better equipped to help find the real root cause of bugs, and more teams actually tried to track that data. Were the specs bad? Is there a problem with our process? Did we not write enough tests? Did someone just screw up?

As it is, bug trackers are good at collecting information and letting you create a process that is as convoluted as you'd like to track the work towards coming up with and releasing a fix, but leave much desired when it comes to trying to reduce your overall defect rate.

That said, trying to pin the blame on someone is the absolute worst way to accomplish any of this, and virtually guarantees that any "root cause" information you try to gather is going to be completely useless.

> I wish bug trackers were better equipped to help find the real root cause of bugs, and more teams actually tried to track that data. Were the specs bad? Is there a problem with our process? Did we not write enough tests? Did someone just screw up?

Some of that comes back to the concept of requirements traceability. Unfortunately it didn't quite make the agile cut. So it's languished in the pre-agile SEng world, locked up in clunky, heinously expensive tools.

I had this to say but can't post it on the site:

The European Directive 94/56/EC [1] "on the investigation and prevention of accidents and incidents in civil aviation and repealing" states that:

> ‘causes’ means actions, omissions, events, conditions, or a combination thereof, which led to the accident or incident; the identification of causes does not imply the assignment of fault or the determination of administrative, civil or criminal liability;_

(Art. 2 part 4).

This is said again in the preamble of the same directive, paragraph 4:

> The sole objective of safety investigations should be the prevention of future accidents and incidents without apportioning blame or liability.

I'm sure there are many other legal texts (including in the US) that state the same thing, as it's plain common sense: assigning blame and getting to the root cause of a problem are two very different and separate businesses; both are necessary but shouldn't be conducted by the same personnel and not at the same time.

[1]: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2...

(Why HN doesn't support Markdown, we'll never know.)

Time to file a bunch of "Corporate culture in rapid decline/freefall" bugs...

Although I tend to agree that morale would decline I do not know the full story of the working environment.

If you have an idiot coder that has been there forever and is hard to get rid of then this field would come up in their evaluation. Needless to say it may get overlooked on other peoples evaluation. It may be used as a way to manage some muppet out the company for wasting everyone's time.

But I don't know the full story, the boss may be a control freak and an idiot himself but he may be actually trying to improve working conditions, he just chose the wrong terminology for the field.

At the right company, this field would be hilarious and fun.

Contrast with the Personal Software Process, where each programmer keeps personal records of every mistake they make, no matter how minor.

That the records are personal -- they belong to the programmer -- is repeated again and again.

Because when you keep management-accessible records like this, three stages occur:

1. "We won't use this to judge your performance and it will not be connected to reward or punishment".

2. It is eventually connected, directly or indirectly, to reward or punishment.

3. The indicator is gamed.

I've always said that failure is the best learning experience. It's okay to make a mistake. Just don't make the same mistake twice.

PS. Your boss is stupid.

I so agree. Do something right and you have just done something right. Make a mistake and learn from it, your knowledge has grown.

huuu - some links you may want to send him read: http://codeascraft.etsy.com/2012/05/22/blameless-postmortems...

and if he'd rather check it out in his car, have him listen to John Allspaw and Mike Rembetsy talking about blameless postmortem on the food fight podcast (the relevant part starts around the middle of the show): http://www.foodfightshow.org/2012/05/episode-14-live-post-mo...

A company can likely be 10x (or more) productive if they're shooting for 99% of code being "good enough". It's understood that sometimes mistakes will happen, but you get a lot more done when you know 99% bug-free is OK. What happens with the blame game is that many employees now start to focus on hitting that 100% level, which significantly slows things down, and probably still doesn't result in hitting that 100% bug-free mark. It's just a really bad idea, and is probably instituted by non-technical management.

A lot of ideas sound great to management, and they work too! I mean, other than killing employee morale and resulting in long term loss ;-)

At one of my past jobs, we worked like consultants (we quoted hours that a task would take to get done, tested etc). We filled daily timesheets to ensure that our hours did not exceed our estimates. In fact, the time on those timesheets had to total 40 hours every week. So we worked the full 40 hours. And we billed those 40 hours to the client. In those few months, I was as productive as I've ever been.

Unfortunately, we weren't paid like consultants.. we got a regular salary. Management was doing nothing wrong. They failed to realize that the 'consultant lifestyle' of billing and working in hours only works if there is an equally motivating paycheck to go with it. I've known multiple people to leave because of how hard it was.

You shouldn't need a person to blame field. Good responsible employees will know what they did wrong and work to fix it. And if they don't, having the field in there will only increase finger pointing and people trying to protect their own jobs. And your bottom line will still not improve. So why do it?

"Fix the problem, not the blame." - I first heard this in the movie Red October, I think. The other one that come to mind is John Wooden, the famous basketball coach, claiming that he liked players who made mistakes because those were the ones trying to make things happen.

What is the point of posting this on stackexchange? I found the comments quite childish:

> Put your bosses name in that field for every bug. Convince your teammates to follow that practice, then wait how long this nonsense will last.

> Quit. No, don't look back. Just... quit. In your resignation letter, put Person to Blame: [Boss's Name]

What I would do is try to explain to them calmly and patiently why this is a bad idea. If this does not work, then just refuse putting blame on other people, and encourage others to do the same. If you really must do something childish to protest, put your own name on every bug that you file together with a nonsensical reason why are to blame for it.

But of course. Comments on StackExchange are for quips that aren't whole answers, and they're limited to 600 chars so that can't be much more than quips. The real high quality responses are in the answers.

You should read the first answer, not the comments on the question.

Bad, bad, bad idea. The result is the devs who do most of the coding will get most of the blame that only demoralizes key contributors.

Unless you're also awarding gold stars for every bug-free line of code then this is just an unproductive disincentive.

What happens when there is a "culture of blame" is that innovation falls to zero (or lower). When people are scared of being blamed for things, and potentially also fired with little prospect of re-employment, then they just stick very rigidly to whatever they believe their job description to be, and never seek to explore new possibilities. The classic phrase is "it's more than my job's worth".

In a culture of blame anything new or different is seen as bad, and to be avoided at all costs, because the unknown nature of the new might also bring blame with it.

Reminds me of a case a friend had at his work. They had a (chinese) subcontractor that failed to deliver the component on time so they asked for a report on why this happened and the how it could be prevented in the future.

They expected a long report with the root causes behind the delay, like unclear specifications, wrong estimation scope, unforeseen technical issues etc. Instead they got back a very short and concise reply: "We will find the guilty, and we will punish them"

the git dcvs has a git-blame feature. I guess it depends on the right environment for such a feature to be productive, which would basically mean an environment where "Blame Jim" means, "Go directly to Jim, he's either the goto person for this issue, or likely knows where to get it fixed quickly", instead of "everyone point the finger at Jim". Judging by the massive amount of negative reactions here, I guess there aren't a lot of productive environments available.

Sounds like you have a large team if it's gotten so out of hand that you need to add a field. So isn't your boss the one at fault for hiring a bunch of shit programmers?

Hiring a bunch of shit programmers and putting up a blame field is like trying to patch the Titanic with a band-aid. If your programmers are shit, your boss is the one to blame and should be fired. Adding a blame field will just incite demoralizing outcomes for those who make regular human mistakes.

As one commenter already said: the best way of avoiding blaim is to not make any major modifications or write difficult code. This way you avoid creating bugs. So there is a huge risk that this will reduce productivity.

A root cause analysis should ask "five whys" as to why this happened. Tight schedules, bad specs, improper training? Blaiming everything on the individual who checked the code in is not going to be very accurate, and probably very bad for morale.

Or they could replace the "person to blame" field with a commit revision. It is less personally offensive as the "person to blame" field and still gets to the same analytic data for reviews.

I do agree a "person to blame" field was obviously implemented by a "management only" oriented person to probably cover his/her own ass. Essentially this is a scorecard to give to his higher-ups to say "Hey look Bob is the one with all the issues, no me".

Am I the only person who thought this might just be a joke, or a way to make the whole bug fixing process more light hearted... I don't think I would be offended if my name got put on such a field, because I am sure everyone would end up on it eventually. Reminds me of the time we passed around a duck toy in the office to anyone who screwed up that day.

Time to find a new job. When the people you work for turn into dicks and it makes your work less enjoyable it is time to move on.

Ummm ... so I saw this Q on Stack Exchange before it hit hackers news. There used to be a lot more comments (yes, many of them jokey but still useful, I'd argue). Apparently, at some point after it hit Hackers News it was cleaned up. What do people think about the moderation on Stack Exchange sites these days?

When talking about screwups I aways say "we" assuming the developer will internally acknowledge that "we" probably meant them. Then again, I always feel somehow responsible for an issue even if it is a totally different team.

Things like this rarely happen in a vacuum. There is no doubt a much larger issue of responsibility (or lack thereof) going on that led to this drastic action.

But yes, as mentioned, "Root cause" is a better approach.

That kind of mentality is exactly why it's wrong to have "svn blame" and "git blame" as commands. The very commands that we use to look at code history teach us that it's all about finger-pointing.

I always understood `blame' to be a light-hearted nickname, and `annotate' to be the official names of these commands. By the way, mercurial also has a `praise' synonym, if memory serves me right. (Or was it another one?)

Perhaps a beter approach would be "root cause of failure". It's easy to jump all over this guy, but what he's trying to achieve is a good thing. I just don't agree with the tactics.

Blame the product manager or customers for coming up with the new feature requests. If they didn't give you anything to code, there wouldn't be any bugs.

Response from the boss: http://news.ycombinator.com/item?id=4179298

If person is never mentioned in "person to blame" field, then boss should question whether that person has any meaningful contribution.

Just put 'God' in the field every time. On a more serious note, this will most certainly decrease the quality of the work environment.

People make mistake, 100% of them. People who don't haven't tried hard enough or haven't gone out of their comfort zone often.

Root Cause is great, exactly as the poster says.

You actually have to a analysis to determine this though, and not just load it off on someone.

This is hilarious and scary at the same time.

Pointless field of data -- the only reason any information should be collected should be to help resolve the bug.

A blame field is unnecessary.

Just note the broken revision and `git blame` or `svn annotate` or whatever equivalent you have. :)

That should be normalized to a separate table with a one to many relationship, including a weighting factor.

At my company, we have a written rule to blame our VP for any and all problems.

It let's us focus on fixing stuff.

The simple solution is to add the boss's name to every bug report.

This reminds me that I have not watched "Office Space" recently.

This is false. You're talking about the push system, which is an entirely different kettle of fish.

It should be called the "flame bait" field.

Is "your mom" an acceptable answer?

Tell him to watch "office space".

you should blame the product owner/manager/guy for writing incomplete/vague specs.

Just don't use it.

Anything like this automatically makes me reach for a suitable Dilbert reference... oh, here's one - http://dilbert.com/strips/comic/2008-06-02/

Person to blame: A

Boss to 'A': what happened ? why the bug ?

'A' to boss: I just checked in the code. It was done by 'B'.

Boss to 'B': hey what happened ? Why the bug ?

'B' to boss: I just merged the code from 'C'.

boss to 'C': hey what happened ? Why the bug ?

'C' to boss: My code worked fine when I unit tested. I gave it over to 'D' to integrate.

boss to 'D': hey what happened ? 'D' to boss: I integrated fine when I did. It is the damn software that might have crashed at the time and code was not integrated properly.

boss to himeself: Fuck it was the damn software.

Boss to the team: That's it, no more software!