Are you swimming in the Developer Pool? January 19, 2007
Posted by scottpulver in Software Development Methodology.trackback
<intro>
Are you working for one of those recently “enlightened” organizations that has put you in the developer pool? If you don’t know what I’m talking about then you have somehow managed to avoid this. Good for you! If not, someone most likely pushed you in the pool. Not many practicing developers want to swim in that particular pool. But don’t dispair because I predict the developer pool will eventually spring a leak. They’re going to have to pay a lot to repair the pool too. If someone actually did a multi-year accounting. The numbers prove was not the fiscal treasure chest they though it was. Later on, many developers will later on find themelves out of the pool completely even though your managers won’t admit it.
What happened to cause all this in the first place?
I’m not going to name names here but in the passed couple of years, I’ve been hearing more and more about the reorganization of developers into “developer pools”. You know. It’s just like the secretarial pool from the 1930’s except it’s for software developers. No, I’m not kidding. Read on.
You’re working for a very large corporation. Your one of the senior VP’s, let’s say for a company around 52 thousand employee’s or more. The business folks are so tired of waiting for their projects to be started, they begin threatening you. They’re going to go to the outside for help and they don’t care what development standards you’ve got. You don’t want that - what do you do? Well, you do what all good Sr. VP’s do. You call in a management consultanting firm. This well established consulting firm, recommends you form a “developer pool”. They have a another customer that just implemented this and they’re recording huge improvement in customer satisfaction for very low additional cost.
You have misgivings at first but you have to change something because all good managers know if you don’t change something then things will stay the same and you’ll find yourself out of a job cause you didnt change something. So, no problem you say. Your ready to setup the developer pool.
The notices to managers go out. It’s something like this. We’re not doing this right now. But I need you to inventory your software developers. Have them fill out this skills assessment form. We’re not doing anything with it right now though. So here ya go. You start filling out the sheet. The sheet only has 20 skills on it. You also realize they could have sent you a sharepoint link and that some poor fool will be data entering this. Not my problem you think and move on. Your feel frustrated because you’ve developed alot of specialized skills that not on the form! Help! You mention this to your manager. She tells you not to worry about it cause there not going to do anything with it. Just fill it out.
Back to Senior VP. Took longer than you thought to get the info you needed. Now you send the word out to the business units. We’ve been listening. We’re set to double our capacity to process our current pending projects queue. Yadda, yadda, yadda … we’ve got a lot of great developers with great attitudes that we’re relaxing in business units that we’re using them to capacity. Well some of that was true …. kinda.
Sounds pretty good to the business person. Well it should since their going to get some attention now. Is it good for the company? Is it the most efficient use of software developers ….no and here’s why. Software development is not assembly work. It takes brains and one or the most important factors in the productivity is understanding the problem domain. The develop pool oddly enough doesn’t address that dynamic. It more or less treats developers as if they were all equal interchangable commodities. Why if that were true, we might as well have our development work done in India or China! Whoops, can I get a mulligan on that? Crap too late. Ok, now you know my topic for my next article, “Why you should insist on learning Hindy or Chinese as a second language and not Spanish in high school”. If you reading this and the year is beyond 2015, please replace Hindy with African County and Chinese with South American country.
Ok. Why does the corporate developer pool nonesense… and don’t worry guys the same business folks that more or less prompted the change will be the same people lobbying IT senior management to change it back. So hang in there. The senior IT executive that actually inacted the high priced consultants recommendation, will eventually realize that she was duped by that consultanting firm whose data was empirical and short lived.
The concept does make sense.
<fill in>
The concept actually only works for a while. Pretty much because the initial perception is that the business areas waiting for resourses are getting some attention now. Which is true.
It’s working for us, what are you talking about! Address that for some large organizations, the pool concept will work at first. In fact it may still be working in some places. Some big corporation are measuring the real costs and discovering cracks in the theory. Over time, the concept will breaks down. Especially as the organization develops larger and larger inventories of software.
<fill in>
Why doesn’t the concept hold over time …
Initially seemed to work. Perception was much of it, but when IT starts to measure the cost of maintenance, retention has declined and the influx of replacement talent cost more and is harded to get (crap the word is out) and overall your tired of hearing complaints from developers and now also from the business people because the cost of maintenance has sky rocketed and is very slow. You also know that code consistency and quality is declined. Your getting bad reports from your architecture team. They can’t control it. Worst case, some code assests were misplaced. You were able to recover them from your offsite storage provider but it scared you. It never happened before.
<fill in>
We thought SOA would prevent the degradation of the developer pool momentum my consultant told me about. Why didn’t it? Because SOA is an altogether different technology and solves different problems.
<fill in>
What adjustments or variants might work and why …
Developers that stay generally speaking in the same problem domain will produce more software or higher quality for less over time.
The pool concept still exists, but it’s filled primarily with contracted labor. You work HARD on your interviewing process and now through word of mouth things are improving at the Corporation X your getting and better candidates.
<fill in>
Comments»
No comments yet — be the first.