Tales from the Crypto

         Alun Jones (Security MVP Reconnect) writes about security, cryptography, SSL, PKI, and pretty much anything else that bothers him enough.

August 12, 2006

I’m a developer – I don’t do operations.

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.

1 Comment

  1.   Scotty — August 15, 2006 @ 5:33 am    Reply

    I think you can widen this out to more than developers.

    My primary responsibility is architecture / design of Windows, primarily AD, systems and I like to think I am good at it. I feel I am less good at implementation and least good at operational support. Maybe I am just less comfortable doing them or just plain don’t like doing them.

    Doing them though is invaluable as often implementations fall down because of a misunderstanding of the plans in place or a need to adapt and the adaptation is not in the ‘spirit’ of the design. Quite often the cyclical ‘thing’ happens where the design evolves due to implementation issues.

    I also think that the best, and only workable handover, is from implementer to operator.

    I have found the best way to keep capable of the work required to participate in carrying through my sort of projects where I am often the technical lead for the initial design is to drop down the food chain progressively to just another team member doing the operations and showing people how it all interrelates.

    The biggest problem I have with getting other people to work this way is ego – they just plain can’t cope with not being the most important person all the time.

RSS feed for comments on this post. TrackBack URI

Leave a comment

© 2017 Tales from the Crypto   Provided by WPMU DEV -The WordPress Experts   Hosted by Microsoft MVPs