What do you get when you throw lots of programmers at a problem? You get lots of code! That's what programmers do, duh. It does not matter how simple or complex the problem is. For any given size problem, more programmers will mean more code. That is more code to debug, more code to test, more to maintain. More, more, more. Eventually this will require even more programmers and the cycle continues until the project collapses.
And it is even worse if you only hire the best and brightest programmers (don't we all!!). They write code faster! And it will be more complex than a dullard programmer because good programmers like to write general solutions.
Rich companies like Microsoft can keep this going for some time. However, you see the result in Vista and Office. Bloat, bloat, bloat.
What do you do if you have a problem that would take 12 months for 2 programmers but you want it done in 6. Hire 2 more programmers? Hire 4 more programmers? Big mistake! First off, it ain't gonna happen in 6 months no matter what you do if it is really a 12 month problem. If you must cover your ass as a manager and claim you used all your resources to make it happen in 6 months, I suggest the following.
Put 2 of the best programmers you have on the project. Make sure they like each other and think alike about software design. They are the leads. Only the leads will write code that will go into production.
Use all your remaining dollars to hire programmers who will support the leads but NOT write production code unless it is a piece of boiler plate delegated to them by one of the leads. What these junior developers do is write and execute unit tests for the leads. They write test tools when appropriate. They participate in code reviews. They are not slaves but future leads in training. Or maybe they are not future leads in training. Maybe they are salves. That's okay, mediocre programmer's need to eat to.
Some bigger projects may need 4 leads or even 6. If you have more than that your project is DOA and you better convince someone to spilt it up. If they won't, I'd find another place to work. That's better than being canned or losing all you hair/sleep/health over a doomed project. And trust me, it is doomed.
Subscribe to:
Post Comments (Atom)
7 comments:
I don't agree. A lot of bad programmers create more code, but a lot of good programmers will critice each other and encourage each other to refactor the code to less lines.
To compare with Vista: Linux is made by many more people then Windows, but Windows has a lot more bloat.
anonymous// now that's just a subjective comparison with no real basis. Show me the actual measurable evidence of that.
Anonymous,
Open source projects have a totally different dynamic that the in-house closed source projects I was largely blogging about.
1) Not everyone who works on open source is a comitter.
2) Very few contributors are doing it as a full time job.
3) There is usually not a fixed drop dead schedule in an open source project.
4) The leads in an open source project are not going to accept massive chunks of code anyway.
I am sure there are numerous other differences I am failing to mention.
The open-source model is a woderful but there are many reasons why that model will not work in most corporate scenarios! Agile processes can work in corporate and those processes usually advocate small teams.
Anonymous,
Open source projects have a totally different dynamic that the in-house closed source projects I was largely blogging about.
1) Not everyone who works on open source is a comitter.
2) Very few contributors are doing it as a full time job.
3) There is usually not a fixed drop dead schedule in an open source project.
4) The leads in an open source project are not going to accept massive chunks of code anyway.
I am sure there are numerous other differences I am failing to mention.
The open-source model is a woderful but there are many reasons why that model will not work in most corporate scenarios! Agile processes can work in corporate and those processes usually advocate small teams.
> What these junior developers do is write > and execute unit tests for the leads.
I think being the lead should not exempt from writing tests. Especially if they are written before even writing code, aka TDD.
What you are suggesting is have 2 people write code, and two "slaves" struggle with writing tests for that code that might not even testable.
In my experience, the best and the brightest write LESS code... well... not really... just me (but it sounds nicer :) )
I can write code faster, but I write less code, because:
1) I spend more time thinking on what is the actual problem and the best solution.
2) Write code I can reuse in the same project (or remove duplicate code)
3)I assemble previous generalized solutions
4) (the real reason) As much as I enjoy coding, is risky and costly for the project
4) (the real-real reason) I'm to lazy to write and debug code, so I try to minimize the coding I need to for solving a particular problem. That gives me time to surf the web and post blog comments :D
Gabriel,
Unfortunatly, although you are right, there are far more "smart" coders than "talented" coders. Your describing what a talented coder tries to achieve ... more with less.
There is also the dueling frameworks problem where a new guy come along and creates a "better" framework but the old code remains in the old framework.
-Sal
Post a Comment