|Perl: the Markov chain saw|
(jcwren) Re: Hackers, Writers, and Productivityby jcwren (Prior)
|on Mar 17, 2001 at 05:02 UTC||Need Help??|
Let's assume two different scenarios here: The first is that a company is in the business of producing software, i.e. that is the product that produces revenue, in a more or less direct fashion (your product may be a spreadsheet, or your product may be a video card, and you need drivers to sell the card). The second is internal projects. These may be for the purpose of streamlining a process, such as inventory control, bug tracking, financials, whatever. The whole point is that no company that has expectations of a good bottom line pays people to write code that they don't use. (Yes, this happens, but it's a damn poor business practice, reeking of poor management, lack of communication, etc).
A large part of the game is resource management. Programmers are a resource to the company. Resources have to be allocated and managed, just like cash flow. Schedules are based around what your performance is generally believe to be (at least, at the start of a project. Often, as features are added, management assumes that the delivery date will not be changed, but the deliverables will).
So, your working on project DeadFish, and the schedule says that you'll be working on the FinFlap section, and that according to the ubiquitous Gant chart, it will be done in 3 weeks. It says it'll take 3 weeks on the Gant chart, because they said it will take 2, and you pitched a bloody hissy fit saying no way in hell can in be done in 2, it'll take 3 (knowing it'll take one...)
So, you write your 10K lines of code, and it's a work of art. This code looks so good, people will speak of it for years in awe. But it doesn't work. It looks bad. Working weekends kind of bad. The "I could quit now, I can pay bills for 5 weeks until I find a new job" kind of bad. You've blown the Gant chart, you've eaten your personal 2 weeks of padding, and the week they built in because programmers always lie.
Meanwhile, the person the next cube over, who you consider a complete incompetent, and not fit to write Visual Basic, has met the objective for his BladderControl section. It's not pretty. It's look like a ferret on methadrine wrote it. It's so ugly, emacs tries to reformat it on it's own, just to bring harmony to the universe. But it works. At least, it hasn't crashed yet, and that's not bad...
So what's management see? The FinFlap section doesn't work, the Gant chart is blown, but DeadFish can hold it's vertical position in the water because BladderControl works just fine.
So... What does this mean? If a company has no metric to measure your output by, they have no way of evaluating your contribution to the project, or ultimately, the bottom line. Some metrics are arbitrary, such as number of lines of code per day. These are generally unfair to the majority of programmers, for obvious reasons. Unfortunately, many companies are not in the position to evaluate the quality of code, and if it works (regardless of maintainability) it's considered adequate. Regardless of how ideal peer reviews and such sound, I have yet to work for a company were that was actually implemented.
This is a valid statement by management, generally speaking. After all, your part of the schedule in the project is producing a certain (working) piece of code. A customer isn't going how much of an eyesore BladderControl is. He wants his bionic fish to float. (It would be nice if it could move forward, but you've blown that.) And the companies revenue stream (and hence, your continuing employment) is based on shipping those 451 bionic fish.
Productivity *has* to be measured, by some standard or another, or companies can't build a schedule, can't deliver product, can't get revenue, and can't continue to pay you to sit and read www.perlmonks.org all day.
What represents valid measurements of productivity? That depends a lot on the manager. Working lines of code per day is an easy metric for a manager (regardless of PHB status) to evaluate. Apply a reasonable window, you didn't complete the goal, you're the problem. However, as we all well know, sometimes you sit and stare at the screen for 3 days, and in a sudden burst of caffiene inspired insight, whack out 800 lines of flawless code.
Probably the most reasonable metric is a combination of how well you meet consistently meet the scheduling goals that you've agreed to, and peer reviews. If you consistently overshoot deadlines, scheduling needs to account for that in the next project (assuming you didn't bankrupt the company because of this one...), you need to better assess your skill set, and your manager needs to ride a tighter herd on you. If you consistently get hammered in peer reviews for not meeting coding standards, get a new job. Obviously you're not a team player, and can't follow some basic formatting rules. If you're the only person on the team, who cares? You won't be there when the next person has to worry about what you wrote.
If you always meet deadlines, and pass peer reviews (or smirk to yourself just how elegant this code is that no one will ever see), you're doing good. Keep doing it.
If you're always twiddling your thumbs when deadlines come around, perhaps your not being challenged enough (you did use the new TPR coversheet, didn't you? ). Set more aggressive deadlines, or offer to pick up more sections. Remember, management usually doesn't like to see idle people, regardless of how good you are. Idle programmers are an under utilized resource, which means there is waste. It's not a 'reward' to finish 4 days early, then play Quake all day. Or surf www.perlmonks.org...
Some companies are unable to comprehend the concept of the individual. Ideally, you should work with your manager to set a metric based on your personality. This rarely happens, because managers are management, and often not plugged in to how programmers work. Sometimes, managers are programmers or engineers who have gone to the Dark Side. At some point, the usually forget their past, and start developing unreasonable expectations (or worse yet, try to 'help'). Try to get them fired as soon as possible, for they will be a living hell. The best you can hope for otherwise is to come to a metric set that you, your co-workers, and your management can all agree on.
It may be difficult (and some of the engineers / programmers may deliberately make it so) to measure productivity. But it *has* to be done at some level or another so that product can be shipped, and all the processes that go in hand with that can take place. Authors, by the way, usually have deadlines. Productivity is usually based on completing so many chapters within a certain period. Book sellers don't work on open ended schedules for most payed work, because they have to set up the marketing that goes with all the functions of publishing and distributing a book.
Unfortunately, productivity has no absolute value like manufacturing typically does (you know that equipment can produce 'x' units an hour, you have an expected equipment downtime of 'd' hours per 'n' hours of running). Yet, you are producing a product (the code. Maybe some documentation, if they're lucky), and sooner or later, some kind of formula can be applied to measure the productivity of that particular worker unit. It's in your best interest to find it. Why? Because it's far worse to be perceived as an under-achiever than an over-achiever, when in reality it's a function of the measurement system being used.
As a final note, although you may resent the person next to you who does an inferior job, don't waste your time and focused anger on them. Instead, direct that hate towards the RIAA and DMCA. That person's evil code incarnate will eventually catch up to them. Worry about the image you project, and what you can do to make it look like you're another Damian Conway / Alan Cox / <insert your favorite respected programmer here>--Chris