devRant - A fun community for developers to connect over code, tech & life as a programmer

When Do You Stop Taking Responsibility?

Let me clarify by describing four scenarios in which you are tasked with some software development. It could be a large or small task. The fourth scenario is the one I'm interested in. The first three are just for contrast.

1. You either decide how to implement the requirements, or you're given directions or constraints you agree with. (If you hadn't been given those specific directions you probably would have done the same thing anyway.) **You feel accountable for the outcome**, such as whether it works correctly or is delivered on time. And, of course, the team feels collectively accountable. (We could call this the "happy path.")

2. You would prefer to do the work one way, but you're instructed to do it a different way, either by a manager, team lead, or team consensus. You disagree with the approach, but you're not a stubborn know-it-all. You understand that their way is valid, or you don't fully understand it but you trust that someone else does. You're probably going to learn something. **You feel accountable for the outcome** in a normal, non-blaming sort of way.

3. You're instructed to do something so horribly wrong that it's guaranteed to fail badly. You're in a position to refuse or push back, and you do.

4. You're given instructions that you know are bad, you raise your objections, and then you follow them anyway. It could be a really awful technical approach, use of copy-pasted code, the wrong tools, wrong library, no unit testing, or anything similar. The negative consequences you expect could include technical failure, technical debt, or significant delays. **You do not feel accountable for the outcome.** If it doesn't work, takes too long, or the users hate it, you expect the individual(s) who gave you instructions to take full responsibility. It's not that you want to point fingers, but you will if it comes to that.

---

That fourth scenario could provoke all sorts of reactions. I'm interested in it for what you might call research purposes.

The final outcome is irrelevant. If it failed, whether someone else ultimately took responsibility or you were blamed is irrelevant. That it is the opposite of team accountability is obvious and also irrelevant.

Here is the question (finally!)

Have you experienced scenario number four, in which you develop software (big as an application, small as a class or method) in a way you believe to be so incorrect that it will have consequences, because someone required you to do so, and you complied *with the expectation that they, not you, would be accountable for the outcome?*

Emphasis is not on the outcome or who was held accountable, but on whether you *felt* accountable when you developed the software.

If you just want to answer yes or no, or "yes, several times," that's great. If you'd like to describe the scenario with any amount of detail, that's great too. If it's something you'd rather not share publicly you can contact me privately - my profile name at gmail.com.

The point is not judgment. I'll go first. My answer is yes, I have experienced scenario #4. For example, I've been told to copy/paste/edit code which I know will be incomprehensible, unmaintainable, buggy, and give future developers nightmares. I've had to build features I know users will hate. Sometimes I've been wrong. I usually raised objections or shared concerns with the team. Sometimes the environment made that impractical. If the problems persisted I looked for other work. But the point is that sometimes I did what I was told, and I felt that if it went horribly wrong I could say, "Yes, I understand, but this was not my decision." *I did not feel accountable.*.

I plan on writing more about this, but I'd like to start by gathering some perspective and understanding beyond just my own experience.

Thanks