|P is for Practical|
Re: code-sharing at work.by sfink (Deacon)
|on Mar 24, 2005 at 18:36 UTC||Need Help??|
Step 1: Fire half the team. It doesn't matter which half.
In detail: to me, it sounds like the problems you are dealing with are all due to complacency. If you had half as many coders, you wouldn't have time to write three separate systems. Developers, myself included, often don't work well without some form of external pressure. Constant awareness of the imminent doom of my company is one thing that works well. Just generally being understaffed and overworked also works. If you give me a sense of time and job security, I'll happily go off and overbuild all kinds of systems, tuning them to work exactly the way I think they should. So will my coworkers, and we won't feel like combining efforts too much because we're too intent on our own endeavours, and there's no pressing reason why we should -- in fact, it's probably better to get things right in such a situation.
Of course, in truth whenever you're feeling relaxed like that, you're probably wrong. (Ok, so I'm from the startup world. Maybe it's different in the huge dinosaur companies.) Odds are that you're cruising full tilt at an unseen iceberg, and by the time you notice it, it'll be too late to throw all of the excess code overboard. Instead, you'll suddenly realize that all of those wonderful systems you leisurely built are falling to pieces when you start scaling them or begin applying them to the actual (and somewhat unexpected) problems that you really face. Which leads me to...
Step 2: Hire everyone back and have them write tests and automation infrastructure.
You commented that you now realize what a sorry shape your code base is in -- poor tests, lack of documentation, no code reviews, etc. Don't worry too much about it; anyone who looks honestly at their own organization will probably see the same thing. Even if they've figured out how to aggressively write tests or do code reviews or whatever, in most cases that just means they've lost sight of other things (or are in process deadlock, which is a whole other topic.)
So if you combine the two observations that your code base and processes need some work, and that you wouldn't need so many developers if you shared more code, then you inescapably realize that you have bandwidth to spare for writing tests. Or automating deployment, instrumentation, testing, load testing, documentation, or whatever. Of course, the people who are stuck with those tasks are going to quit, so...
Step 3: Spread the love
Now you just have to combine tasks so that each person is doing both development and testings/automation/documentation/whatever. You'll prevent people from getting burned out, and the coders will be incented to make things more easily automatable, testable, and documentable.
Of course, it would be better to skip steps 1 & 2 and go straight to step 3, but in all fairness I still have to mention...
Step 4: Realize that my post here is useless because it only describes the way things ought to be, not how to make them that way.
The only last thing that I'd like to point out is that I doubt the dichotomy between the "don't fix its" and refactorers is terribly relevant. I think both groups are suffering from the same illness, namely complacency. The "don't fix its" are complacent in thinking that the existing code is good enough, even though it hasn't been sufficiently tested and reviewed, and probably hasn't been stressed much for its adaptability. The refactorers are complacent in thinking that they have the time to spend tuning and fixing and tweaking. It doesn't sound like either group has enough data to knowledgeably choose one perspective or another. That data can be acquired from code reviews and test harnesses and performance data and automation suites. And don't forget trial by fire.