Joe Armstrong on Programmer Productivity

FTA (favorite part for me)

Most time isn't spent programming anyway - programmer time is spent:

    a) fixing broken stuff that should not be broken
    b) trying to figure out what problem the customer actually wants solving
    c) writing experimental code to test some idea
    d) googling for some obscure fact that is needed to solve a) or b)
    e) writing and testing production code

e) is actually pretty easy once a) - d) are fixed. But most measurements of productivity only measure lines of code in e) and man hours.

For me, b) is a bottleneck. c) is far and away my favorite part. Nothing like green-fielding . . .

My last job was in an agency that used to build websites for a fixed cost. After a few years of doing it we changed the policy so that integrations were charged as time and materials. You just can't judge how long it's going to take when you have to deal with an external organisation. Hell, one of the projects I was working on before I left (a year ago) was started 2 years ago - and it's still going on. It's just a simple authentication integration but they're at the mercy of the other party. No actual code has been written but plenty of developer hours have been wasted - including mine.

I'm not sure the growth in the amount of software in the environment (contributor to A) is really that much of a problem. After all, he says we might have "thousands" of times more software, but we certainly aren't spending thousands of times more fixing it. That's because today's software is significantly less broken than the software of yore.

We're standing on the shoulders of giants. Underlying most of our environments is Unix (or Linux, same diff), which is basically the same as it was 20, 30 years ago. We're also running on http, an astoundingly good design. There are lots of other basics, none of which are all that complex, and all of which are finely tuned.

More to the point, a) represents a practical limit. If our environments get too flaky due to poorly understood configuration or bugs, we ultimately can't get programming done. But not pushing to where it hurts some means not using the latest, greatest tools that can amplify our power as programmers - the same tools that let us have thousands of times more software than we used to, without losing any more time to configuration/bugs than we did decades ago.

And beyond that, a lot of the business opportunity in the industry lies with running along just behind the bleeding edge, being firstest-with-mostest to the new and powerful technologies. So unless you're in a safe business relatively independent of new tech, you're going to bleed a bit.

Then there's Facebook.

"We integrated with Facebook a few months ago, it should be easy to do it again."

Famous last words. I've lost count of how many times I've become an "expert" at some aspect of Facebook integration to have it be completely different just a few months later. Google is also really bad about this, at least in the past year or so. It almost makes me want to quit webdev and be a dba or something.

The problem is that the assets are dynamic. If you give me a single complete requirement for some little feature I can give you a pretty accurate estimate. But most of my requirements are things like "Write an app to do X." The only part of that I can estimate is the part I've done before, but if the app were just like all the apps that came before there would be no need for a new app. But the juicy candy center is an abject mystery and there is nothing to compare it to from which to derive an accurate estimate. Once you've dug halfway into it, you'll be tossing out new requirements. Maybe you can make good estimates on those, but your a priori estimate is now probably really off.