Re: Hackers, Writers, and Productivity

[idnopheq]

My company tried such a "productivity evaluation system" thing. They combined it with a more typical "performance evaluation" as to an employee's value to the company. They found that the two rarely matched up. One oddly inquisitive upper-management type, heavy in statistical wizardry, investigated why top people, whom everyone knew were top notch coders, ranked very low.

Turns out the whole system was flawed. There is often a variable the powers-that-be fail to calculate: changing requirements. So, these "artists" are tied up in monolithic meetings to nail down what is needed now and if the new requirements can be coded. Then, existing code receives a make-over.

Thus, the rewites occur two or three times ... not the best use for top-rate tallent. This often leads to 'feeping creaturism' syndrome, and poor productivity in the classic sense.

For example, and simple shipping-and-receiving project sending batch jobs to a legacy, big iron-based inventory tracking system became a wholesale replacement of the big iron. Hard to estimate and judge the project size and associated productivity if no updates to the the project's scope occur.

The moral of the story is this: The front line managers should, if they are worth their salt, know what the programmers are up to (w/o micromanaging) in relation to the world as it exists today. The manager should be trained, objective, but relaistic in this most basic of management skills. The manager must be aware of the overall and their group's role. Read Sun-tzu and Covey.