The Science of Debugging
2.6 Programmer Payoff


2.5 Programmer Payoff


There's still a minor point that needs to be made, but it's an important one. Code written with well established plans not only tends to integrate more easily, run faster, and err less often, but it also makes the programmer's job easier.

We'll assume that the majority of programmers working on MUDs amd other Open Source projects are both volunteers, and volunteer because they actually enjoy writing code. In a volunteer job (like programming on most MUDs), happiness is the only payment a programmer gets. If you want to keep your programmers, you need to keep them happy. That means that if you are the administrator, it's your job to keep them happy.

I can tell you from first hand experience, it doesn't make me happy if I am forced to do every step between requirement gathering to implementation when it's entirely someone else's pet project. As a programmer, I want to do MY projects, implement MY ideas. I want to do fun things with code, not add some tired old adaptation of a lightning bolt spell. At the same time, I know that other people's things do have to get written, and that I'm going to be the one implement them. The best an admin can do for me in that situation is to make sure I don't have to sit at your feet asking questions every 20 seconds, or make me actually have to use my creativity to make your idea useful. This is especially apparent with messages that are sent to characters - given no direction, a programmer will be just as likely to copy another existing message, or write short unhelpful messages like "Ouch". Now you have an unhappy coder and crummy player interaction.

Make the programmer do the extra work, you get an unhappy programmer and crummy code
You do the administrative work, you'll get a happy programmer, and good code.

You do the math.



Index
2.4 Administration Payoff. 3.0 CVS