rss feed
driver: We're not at the stop yet.
passenger: But my stop's here!
driver: We'll get there.
passenger: You're in the wrong lane.
driver: Just wait one minute.
passenger: What about my stop?
driver: Listen, man, my job is to do all the driving, navigate through traffic, and get you to your stop. Your job is just to sit there and wait til I open the doors. That's all you gotta do. It's real easy. Just sit there and wait til the doors open.The man grumbled, and we continued to inch forward. When the bus finally got to the man's stop, he muttered a sarcastic "thanks" and stalked out. But the driver had the last word.driver: Have a nice day. I'll let you take it from here.This sort of backseat driving shouldn't be unfamiliar to anyone who writes code for a living. It's not at all transparent to non-developers what you're doing all day clackity-clacking away on your keyboard. People who have a stake in getting their hands on the results of your labor, whether that's managers, salespeople, or customers, often feel like they need to tell you how to do your job.When backseat driving happens, it's hard to miss the signs. Usually it takes the form of someone not at all involved in actual development reaching down into the dev process and handing you a pre-engineered solution for some pet feature. By "pre-engineered" I mean a solution that is already designed in detail before it ever gets to your inbox, and quite often before an actual engineer ever sees it.These solutions can be vague, ill-conceived, poorly considered, or all three. But backseat engineering never comes without a rationale. A common one is that timely completion of the feature is of the utmost importance to satisfy some demanding customer or a predetermined release date, and so there's no time to get questions answered or, heaven forbid, assess the existing "design" to see if it's any good. This rationale for backseat coding, by the way, is called playing the schedule card.Another common rationale for backseat engineering is that "It's what the customer wants." In other words, some scrawled ideas for the pre-engineered solution have been briefly flashed in front of the customer at some point, and without actually sitting down to hash out requirements, the customer has agreed to the solution. There's no need to think about the design or raise any questions, because after all, it's already exactly what the customer wants. This rationale for backseat coding is called playing the customer card.So what's a poor software engineer to do when faced with a pre-designed feature to implement? Well, there are a couple of options. Let's run through them in increasing order of ending your day unemployed.option 1: Keep your big mouth shut, and code the damned feature.You know that the customer was never asked what they are really trying to accomplish with this feature. You also know that for that reason alone, your implementation will probably not turn out to meet the customer's needs. But no one likes a boat rocker, so you just develop the feature anyway. This has the benefit of keeping everyone happy at first, but when you deliver the exact turd they asked for, the customer won't be grinning anymore. Oh, and each time you just grit your teeth and neglect to point out glaring design problems, your die a little on the inside.option 2: Code the damned feature, but document and publish the questions and concerns you have with the "design".This is more of a CYA technique. If at some point it becomes apparent that the solution as pre-engineered is utter crap, well, at least then you can wave around the emails you wrote months before containing all your objections. There is a certain amount of soul rot to this option as well, because although you can smugly say you knew it was a bad idea all along, well, you did nothing to prevent it from getting implemented.option 3: Firmly request some additional requirements gathering before you start coding the feature.This are a few ways this can go. Depending on the tone you take, and the questions you ask, and whether the party attempting to engage in backseat coding is in a good mood, you can sometimes actually get answers to your questions and somewhat refine the granularity with which the pre-designed solution is specified. If the pre-engineering wasn't too terrible to start with, this can even get you enough information about the design to code something moderately reasonable. You'll look like a hero for being thorough and asking good questions, the customer will actually get something roughly resembling what they want, and everyone will go home happy.However, if you're unlucky enough to have a real stinker of a pre-designed solution, then no amount of asking for clarifications will magically turn it into a good design. You'll end up looking bad for turning out a poor solution, even if that was just because the design sucked, and the customer will be very angry and jump up and down.Often though, especially when people are playing the schedule card, they don't want to hear questions. No matter how good your intentions may be, backseat coders in a hurry think you're not a team player if you ask questions. You have a design already, what are you waiting for? Just start coding already. In this situation, once questions have fallen on deaf ears, coders often resort to options 1 or 2.option 4: Provide a detailed estimate for how long you'll take to implement the feature as designed.This option can be a good one if one of the reasons why the pre-engineered design is so bad is because no one has stopped to consider how long it will actually take to implement. The idea here is to communicate to the backseat coder, ideally in unbearable detail, the true cost of what they're asking for. Don't inflate numbers, just call it like you see it. Pie-in-the-sky feature? Well, break that up into pie-in-the-sky task 1, pie-in-the-sky task 2, and so on.This option can be particularly effective if you couple it with a set of clarification questions, pointing out that the answers to the questions may reduce or increase the time estimate. Even better, provide some alternate design ideas and estimate their development time as well. That way, you can first point to the original pie-in-the-sky design that will take an estimated 6 weeks, and then draw everyone's attention to your bold, alternative design that will take only 3 weeks to develop.If you choose this option, be aware that you are playing with fire. If it works, the backseat coder will reconsider their request and maybe revise things, ideally taking your input into account. And you'll get to code something that actually makes some sort of coherent sense. But if it backfires, you will face the wrath of an angry backseat driver, who will not only jump up and down, but will mutter a sarcastic "thanks" as he or she stalks out of your bus.option 5: Flat out refuse to implement the feature as designed, but offer a good, alternative design.This is not generally recommended, because unless you have a tremendous amount of accumulated good will and/or other job security, it will probably get you canned. But it often really is the most honest option. In case you're having trouble coming up with what to say, consider the following:"No offense intended, but your design is crap, largely because it was created by someone completely untrained in software development. I wouldn't expect myself to be able to do your job any more than I expect you to be able to do mine. But don't worry, I've come up with an alternate design that is vastly superior."Well, at least if you get fired over this you'll know what website to use to find a better employer.
blog - 5 ways to deal with backseat coding
posted by witten on March 14, 2007
I was riding the bus to work today, and as we drove into downtown Seattle, a sea of stationary cars filled the road before us. The bus slowed to a stop, and over the next several minutes I'm pretty sure we made a good ten feet of forward progress.A man sitting near the front of the bus turned to the driver, and the following conversation ensued.passenger: My stop's right here.driver: We're not at the stop yet.
passenger: But my stop's here!
driver: We'll get there.
passenger: You're in the wrong lane.
driver: Just wait one minute.
passenger: What about my stop?
driver: Listen, man, my job is to do all the driving, navigate through traffic, and get you to your stop. Your job is just to sit there and wait til I open the doors. That's all you gotta do. It's real easy. Just sit there and wait til the doors open.The man grumbled, and we continued to inch forward. When the bus finally got to the man's stop, he muttered a sarcastic "thanks" and stalked out. But the driver had the last word.driver: Have a nice day. I'll let you take it from here.This sort of backseat driving shouldn't be unfamiliar to anyone who writes code for a living. It's not at all transparent to non-developers what you're doing all day clackity-clacking away on your keyboard. People who have a stake in getting their hands on the results of your labor, whether that's managers, salespeople, or customers, often feel like they need to tell you how to do your job.When backseat driving happens, it's hard to miss the signs. Usually it takes the form of someone not at all involved in actual development reaching down into the dev process and handing you a pre-engineered solution for some pet feature. By "pre-engineered" I mean a solution that is already designed in detail before it ever gets to your inbox, and quite often before an actual engineer ever sees it.These solutions can be vague, ill-conceived, poorly considered, or all three. But backseat engineering never comes without a rationale. A common one is that timely completion of the feature is of the utmost importance to satisfy some demanding customer or a predetermined release date, and so there's no time to get questions answered or, heaven forbid, assess the existing "design" to see if it's any good. This rationale for backseat coding, by the way, is called playing the schedule card.Another common rationale for backseat engineering is that "It's what the customer wants." In other words, some scrawled ideas for the pre-engineered solution have been briefly flashed in front of the customer at some point, and without actually sitting down to hash out requirements, the customer has agreed to the solution. There's no need to think about the design or raise any questions, because after all, it's already exactly what the customer wants. This rationale for backseat coding is called playing the customer card.So what's a poor software engineer to do when faced with a pre-designed feature to implement? Well, there are a couple of options. Let's run through them in increasing order of ending your day unemployed.option 1: Keep your big mouth shut, and code the damned feature.You know that the customer was never asked what they are really trying to accomplish with this feature. You also know that for that reason alone, your implementation will probably not turn out to meet the customer's needs. But no one likes a boat rocker, so you just develop the feature anyway. This has the benefit of keeping everyone happy at first, but when you deliver the exact turd they asked for, the customer won't be grinning anymore. Oh, and each time you just grit your teeth and neglect to point out glaring design problems, your die a little on the inside.option 2: Code the damned feature, but document and publish the questions and concerns you have with the "design".This is more of a CYA technique. If at some point it becomes apparent that the solution as pre-engineered is utter crap, well, at least then you can wave around the emails you wrote months before containing all your objections. There is a certain amount of soul rot to this option as well, because although you can smugly say you knew it was a bad idea all along, well, you did nothing to prevent it from getting implemented.option 3: Firmly request some additional requirements gathering before you start coding the feature.This are a few ways this can go. Depending on the tone you take, and the questions you ask, and whether the party attempting to engage in backseat coding is in a good mood, you can sometimes actually get answers to your questions and somewhat refine the granularity with which the pre-designed solution is specified. If the pre-engineering wasn't too terrible to start with, this can even get you enough information about the design to code something moderately reasonable. You'll look like a hero for being thorough and asking good questions, the customer will actually get something roughly resembling what they want, and everyone will go home happy.However, if you're unlucky enough to have a real stinker of a pre-designed solution, then no amount of asking for clarifications will magically turn it into a good design. You'll end up looking bad for turning out a poor solution, even if that was just because the design sucked, and the customer will be very angry and jump up and down.Often though, especially when people are playing the schedule card, they don't want to hear questions. No matter how good your intentions may be, backseat coders in a hurry think you're not a team player if you ask questions. You have a design already, what are you waiting for? Just start coding already. In this situation, once questions have fallen on deaf ears, coders often resort to options 1 or 2.option 4: Provide a detailed estimate for how long you'll take to implement the feature as designed.This option can be a good one if one of the reasons why the pre-engineered design is so bad is because no one has stopped to consider how long it will actually take to implement. The idea here is to communicate to the backseat coder, ideally in unbearable detail, the true cost of what they're asking for. Don't inflate numbers, just call it like you see it. Pie-in-the-sky feature? Well, break that up into pie-in-the-sky task 1, pie-in-the-sky task 2, and so on.This option can be particularly effective if you couple it with a set of clarification questions, pointing out that the answers to the questions may reduce or increase the time estimate. Even better, provide some alternate design ideas and estimate their development time as well. That way, you can first point to the original pie-in-the-sky design that will take an estimated 6 weeks, and then draw everyone's attention to your bold, alternative design that will take only 3 weeks to develop.If you choose this option, be aware that you are playing with fire. If it works, the backseat coder will reconsider their request and maybe revise things, ideally taking your input into account. And you'll get to code something that actually makes some sort of coherent sense. But if it backfires, you will face the wrath of an angry backseat driver, who will not only jump up and down, but will mutter a sarcastic "thanks" as he or she stalks out of your bus.option 5: Flat out refuse to implement the feature as designed, but offer a good, alternative design.This is not generally recommended, because unless you have a tremendous amount of accumulated good will and/or other job security, it will probably get you canned. But it often really is the most honest option. In case you're having trouble coming up with what to say, consider the following:"No offense intended, but your design is crap, largely because it was created by someone completely untrained in software development. I wouldn't expect myself to be able to do your job any more than I expect you to be able to do mine. But don't worry, I've come up with an alternate design that is vastly superior."Well, at least if you get fired over this you'll know what website to use to find a better employer.