> In most organizations the developers are some of the highest paid employees. They get paid well because their skills are scarce and hard to reacquire. This leads to entrenched “senior” developers who produce little, but “know” (and therefore get paid) a whole lot. It also shifts the emphasis to stability and away from being quick, nimble, and adaptive. Over time this turns your development teams into an occupying force rather than a fighting force.
When this process is unhindered a company's right brain starts to wither and die.
He said that, in that week, the code base was reduced by 90%, which probably accounted for a fair chunk of the bonuses. Odds are, the code base won't be reducible by another 90% any time soon.
Now, doing something similar another week for test coverage, or some other way that the code base is lacking, makes plenty of sense. But it doesn't seem viable as a long-term bonus strategy.
Indeed. This seems to be putting a "price" (really, with those numbers, these are just game-like "points", they aren't going to change anyone's compensation meaningfully) on what amounts to the low hanging fruit of the development world.
Yes, all that stuff is good. But you can do all that right, constantly refactor code, write tests to avoid "rolling out bugs caught by others", and still have an expensive, out-of-control project. This just seems like a way to turn otherwise wasted developer cycles in to busywork. It's seems fine, and might be fun for a while, but I can't see this making a huge difference in the long term
[+] [-] benjamincanfly|17 years ago|reply
> In most organizations the developers are some of the highest paid employees. They get paid well because their skills are scarce and hard to reacquire. This leads to entrenched “senior” developers who produce little, but “know” (and therefore get paid) a whole lot. It also shifts the emphasis to stability and away from being quick, nimble, and adaptive. Over time this turns your development teams into an occupying force rather than a fighting force.
When this process is unhindered a company's right brain starts to wither and die.
[+] [-] wildwood|17 years ago|reply
He said that, in that week, the code base was reduced by 90%, which probably accounted for a fair chunk of the bonuses. Odds are, the code base won't be reducible by another 90% any time soon.
Now, doing something similar another week for test coverage, or some other way that the code base is lacking, makes plenty of sense. But it doesn't seem viable as a long-term bonus strategy.
[+] [-] ajross|17 years ago|reply
Yes, all that stuff is good. But you can do all that right, constantly refactor code, write tests to avoid "rolling out bugs caught by others", and still have an expensive, out-of-control project. This just seems like a way to turn otherwise wasted developer cycles in to busywork. It's seems fine, and might be fun for a while, but I can't see this making a huge difference in the long term
[+] [-] acesamped|17 years ago|reply
they're completely useless, but then again, they're oh so useful. haha.