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.
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.")
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.
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.
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
Top comments (4)
I have been in similar situations. I've also been asked to work on software that was unethical and illegal.
Thankfully those last two were over the top enough that I kind of began to develop a sense of my own responsibility.
Over the years and after getting some advice from some people I really respect my answer in all scenarios in all moments is this:
I am responsible.
I'm responsible for the code I write, the words out of my mouth, the thoughts in my head, showing up each day my job, and so on.
It doesn't matter what people ask of me, it doesn't matter what the circumstances are, or how I feel about it. I am responsible for my actions and choices.
Inevitably, this belief leads to a confrontation with people who believe that they own my choices. People who believe they can tell me to work all weekend after a full week. People who believe they can make me write poor, unethical, or illegal software.
I'm not saying that in these cases or moments I was right and they were wrong. Right and wrong are a distraction. We use that to justify what we're doing and why, but to me, the simple truth remains.
I am responsible. I'm responsible for my choices when they're right and I'm responsible for my choices when they're wrong.
This may make me sound very pig-headed, but this is how I operate internally. I'm curious about everything that is asked of me. I want to know everything before I make my choice.
Strangely, in all my years operating this way I've never been fired or demoted. I've been promoted in every job and am looked to for leadership even when my title doesn't command it.
I hear you, and I'm glad you've been able to take that position. But the question is less about what we should do (which may not be quite so black-and-white in every case) and more about understanding the reality of what does happen. For example, many developers must balance accountability for dev-related choices, large and small, with accountability for providing for their families. Not everyone can afford to die on every hill.
Oh Ya. Sometimes you have to choose your battles. I'll always speak my mind, but at the end of the day if I'm asked to build something that is ethical yet doesn't make sense for the business or for the users - after expressing my mind - then I'll kind have to weight out whether it's worth fighting for or not.
I've found, in those environments where this tends to happened a lot, it's usually a lost cause.
For me, the key is to make sure I speak my mind - which I always do. And as you mentioned, this many times will lead to looking for a new job.
So - Yes.
I think most of us have been in position #4.
The main thing that I'm trying to do when in that position is to explain as much as possible all the counter-arguments, in the simplest way possible.
However, there are cases in which it's normal to understand why you need to cut corners, especially if you're trying to build an MVP.
That being said, since I'm always trying to do my due diligence on explaining all the possible outcomes, if everything comes falling down, I don't feel accountable at all, nor do I make my co-workers feel accountable in relation to the project/client if all the red flags were rose beforehand.