People as Replaceable Components
IT shops want people that are replaceable. So they get replaceable people
Posted by 03/15/2006
There is a tendency in IT shops to think of people as components in a larger mechanism - that can be replaced or swapped out. In some ways this mirrors OOP techniques - drop-in a replacement implementation. The programmer is just an interface - implementing program() - with this abstract implementation:
public Language getLanguage() { return JavaLanguage; } or
return CSharpLanguage
The idea seems to be that if you set up enough rules, and limit people enough - then anyone can come in and do that job - no matter what their actual skill level is.
I think this is the wrong approach. I think the actual people that do a job make a difference, and as an organization you should be worried when someone leaves. I've never seen it work that someone is just entirely replaceable. The same is true in life in general, but I'm just talking about work. I've noticed a lot of places settling on Java as their common tool . Are they finding it easy to hire people? Easy to just slot in a new person and have them up and running in days? Not that I've seen.
One problem I've seen for years is the Job Posting that lists a thousand things you are supposed to know:
Developer needed: Struts, J2EE, Hibernate, JMX, EJB, CSS, XML, XSL, HTML, JUnit, SOAP
I read this and have to think to myself "Oh well. I don't know JMX. Got everything else, but you got me on that one. I've heard of it, but never have had a need to use it".
Everyone has gone through a strange path of experience that is often dictated by external forces, and the most important programming skill is how quickly you learn and adapt. I know I can learn JMX in a week or two. If I have to. And the truth is a lot of programmers can learn whatever it is they need to learn pretty easily. There has to be some other way to hire people.
I've worked in state government, so I haven't exactly worked in the most advanced IT departments in the world, but I have yet to see a place that even comes remotely near CMMI compliance. There is a lot of talk, there are checkboxes checked, there is documentation a'plenty - but I still have the feeling of chaos just beneath the surface. And this is even more the case with contractors because they are often not accountable for anything.
Some things people say:
- We should all standardize on [...put anything here...] so if [x] leaves, we can find someone to replace them easily
- Programmers suck, most of the time, so water it down - make it bone-dead simple. Make sure there is an IDE and don't allow any variance in approach
I can't say I agree with either one. If you have no diversity in toolset and skillset, then your stuck running FoxPro applications forever. And I contend that maintaining an application means upgrading it to new versions, approaches, languages etc... And if your programmers suck, well, then your programs are going to suck. That's most likely.
Comments
Post a comment