Okay, so there’s a point that Larry has here, in referring to Dare’s posts 1 and 2 – that operations and development are two separate skills. [Joe refers to it, too]
I’ve suggested for a long time that developers should spend some time on technical support to find out how their customers use the product – not just to get the numbers of “this is our most called-about issue”, but to get an idea of what their target audience really is.
But then, to go with Larry’s argument, tech support and development are two separate skills, and it would seem like a bad idea to do this, because good developers might not be good on tech support, and vice versa.
You can only take this so far, I think – at some point, everyone you employ has to be able to work outside of his or her comfort zone. Take into account that this is not their best side, perhaps, but recognise that the individual will learn far more, and be more useful back in their main role, if they learn something of the world with which their code will interface.
I’ve met too many developers who were developing for a target market that didn’t exist except for a few “powerhouse” customers who could afford to send bullying representatives to persuade the program management team that their desired features were the only ones worth implementing. That’s a great way to satisfy your “powerhouse” customers, but not a great way to build a wide business base.
I think it’s important for developers to understand something of the level “above” and “below” the software they work on. Most developers agree that they need to understand the level “below” their software – understanding the compiler and assembly language, and even a little of how the processor works on code, will generally help you write more efficient code.
But you have to understand something of the users you’re developing for, for the same reason – it will help you write more efficient code for them.
Taken to another direction, you have to understand something of the developers before and after you, in order to continue a chain of maintenance on the code (be prepared to read code with no good comments, but make sure you comment your code – ideally inside the code itself – for the developer to come after you).
Too many developers that I’ve worked with in the past tended to act as if they needed to know nothing about their potential users – “if you build it, they will come”, kind of attitude. That’s fine if you have a captive customer base, but if you want to be competitive, you have to know who you’re aiming for, and target them at all levels – including the developers.
So, yeah, developers shouldn’t be your ops department, or your tech support department, but they should be familiar enough with those departments that they do not generate strife for them, and so that they understand the departments enough to offer solutions that the others do not see.