http://www.perlmonks.org?node_id=65058

It seems that a lot of my Meditations are focussed on how to become a "faster", "more productive" programmer. So I just finished having a conversation with my supervisor to try to answer this question (I brought it up :):

How do you know if you're a productive hacker?

If you get something out quickly, but it's riddled with bugs, what good is that? Not much better to whip something out that works 100% to spec but is nigh impossible to maintain. And then there's the case of writing something that works 100% to spec, that's very well to maintain, but took 4 times as long to ship and your competitors are already $2 million in sales ahead of you. Or what if you can normally pull of writing pretty good code in pretty good time, but you happen to be particularly disinterested in what you're working on, and are finding it difficult to get motivated? And I'm sure that even merlyn spends occasional hours on ridiculously simple bugs, that were so annoying to find just BECAUSE they were so simple!

So can we even measure productivity with any kind of accuracy? Or is being a hacker more like being an author (or an artist), where "productivity" isn't really the name of the game?

The more I think about it, the more I think productivity isn't something that can really be measured, except for in extremely obvious cases (like 2 weeks to change the text of a window's title might be grounds for dismissal :P). Obviously, the more you keep your mind on task, the sooner you'll get things done, and likely with higher quality but other than that, I think "productivity" shouldn't really be the issue so much as staying on task, being creative, always learning new things and having fun.

Replies are listed 'Best First'.
(jcwren) Re: Hackers, Writers, and Productivity
by jcwren (Prior) on Mar 17, 2001 at 05:02 UTC

    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

    e-mail jcwren
      You've made a lot of excellent points jcwren. Although productivity has to be discussed, debated, and quantified by companies or management...I think it's highly difficult to do. I think it's very subjective accordingly to the company, as well as to the manager and the programmers. But with the right company management and coding guidelines/freedom - both company and programmers can be quite productive and happy. Of course, the opposite can be true as well. It sort of reminds me of this...

      you did use the new TPR coversheet, didn't you?

      It's called a TPS coversheet, not a TPR. Didn't you get that memo? I'm going to have to ask you to move your desk again....

      :-)

      BlueLines

      Disclaimer: This post may contain inaccurate information, be habit forming, cause atomic warfare between peaceful countries, speed up male pattern baldness, interfere with your cable reception, exile you from certain third world countries, ruin your marriage, and generally spoil your day. No batteries included, no strings attached, your mileage may vary.
      mondo ++jcwren, though, judging by the novella that is your reply, it would appear as if you've finished FinFlap quite ahead of schedule =)
         MeowChow                                   
                     s aamecha.s a..a\u$&owag.print
Re: Hackers, Writers, and Productivity
by merlyn (Sage) on Mar 17, 2001 at 04:23 UTC
    And I'm sure that even merlyn spends occasional hours on ridiculously simple bugs, that were so annoying to find just BECAUSE they were so simple!
    I recall a experience where we had a field engineer from a vendor installing some Unix software on our Unix-over-VMS system, back when I was stuck in a VMS world.

    He fretted for hours (way past 6pm), trying to get everything in (it was fixed-bid), and was getting very frustrated (I could tell by the muffled occasional "crap" and "damn" coming from his general direction). So was I, since everyone else had gone home, and as the sysadm, it was my job to get it installed and to babysit him until he left.

    So, on a whim, I wandered into his cube area, hoping that maybe I could coax him to come back in the morning, and looked over his shoulder at just the opportune moment to see the code trying at the end of an apparently very long process to create foo.bar.out, and failing. I pointed at the filename, and said "That's not a legal filename for this Unix emulator, because it exposes native VMS names, and they can't have two dots".

    It's a good thing I was out of his backhand range, because he erupted with "WHAT! That's what's been holding me up for the past FOUR HOURS!" and started cursing in a way that even a sailor would be embarassed.

    Moral of the story—sometimes, it's the little things. Second moral—ask when you get an error you don't understand. Third moral—never be within backhand range when you have to point out the obvious.

    -- Randal L. Schwartz, Perl hacker

Re: Hackers, Writers, and Productivity
by Trimbach (Curate) on Mar 17, 2001 at 04:18 UTC
    I think programming is exactly like the work of the author/artist. Larry (capital "L") is right on target making the assertion that computer languages ought to be like other human languages with their idioms and slang and 32 different words for snow. The creative, productive, beautiful expression of language is hard and not everyone does it well, or does it fast.

    When you want to measure programming "productivity" you can't apply the same measures you do in other fields. The productivity of a typist (for example) can be measured in keystokes per hour; the faster, more accurate you are, the more productive you are.

    Authors, on the other hand, are judged far differently. Harper Lee published exactly one book her entire life ("To Kill a Mockingbird") and it is judged a classic and the author is highly praised. L. Ron Hubbard published thousands (and thousands, and thousands...) of pages, but nothing he wrote was as well regarded as Mockingbird. Who is more productive?

    The answer depends on your perspective... Hubbard probably made more money, both for himself and his publishers. No matter what the quality I sure as heck would want him writing for me if money was what I cared about. If I wanted art I'd hire Lee, but I'd probably go out of business waiting on her to crank her (clearly superior) work.

    The productive programmer is in the same boat as the productive author: What are your goals? When would you like to achieve them? How much are you willing to spend? The questions are the same whether you are writing books or CGI's.

    Gary Blackburn
    Trained Killer

Re: Hackers, Writers, and Productivity
by idnopheq (Chaplain) on Mar 19, 2001 at 17:37 UTC
    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.

Re (tilly) 1: Hackers, Writers, and Productivity
by tilly (Archbishop) on Mar 17, 2001 at 23:43 UTC
    Steve McConnell has a chapter in Rapid Development about methods of estimating how big a project will be and how long it will take. He seems to be a fan of function point analysis. I haven't tried that, but it would probably be a good starting place if you want to learn more about how people try to estimate how much work various projects will take.

    On a related note, your estimates are likely to be substantially off because of inevitable feature creep. Steve also recommends watching the movie Bugsy. As he says, ...it's hard not to feel a sense of justice when Bugsy is finally gunned down for changing his mind too often and spending too much of the mob's money. :-)

Re: Hackers, Writers, and Productivity
by dmitri (Priest) on Mar 17, 2001 at 09:23 UTC
    One of the most important criteria of productivity is how well you can estimate how long the job would take. The most important part of the project is the first two hours after you receive your assignment and brainstorming outside smoking cigarettes and eating oreos.

    At least, that's how it is for me.