How to improve programming productivity
Improving programming productivity is a big business, producing a never ending parade of methodologies and processes and research and whatnots. But over the past 40 odd years I think we've learned that there's only four real ways to do it:
- reduce connections
- write less code
- meetings kill kittens
- get better people
(to put them all in punchy short forms)
None of these should be new to people, since Fred Brooks covered them all 30 years ago in The Mythical Man-Month (with much better writing, and using different labels).
It's interesting to look at popular methodologies and think about how they try to attack each of these. (These days, mostly they work on #2 and #3; #4 is mostly the domain of management advice books.)
For example, I see a good part of Extreme Programming as a clever attack on #3, since test driven development (and pair programming, and no code ownership) mean it's easier to change things without talking to other people. (And at the same time it needs a base level of #1 and #2, which make it feasible to modify code that you're not intimately familiar with.)
The transition from assembler to high level languages was an attack on both #2 and #1 (since assembler is what you could call a highly connected language). Structured programming, modularity, and OO continued the attack on #1, although many of them did nothing much for #2. High level languages don't just let you write less code, they also attack #1 as they sidestep whole classes of connections (pointer manipulation, manual garbage collection).
And on my favorite soapbox, I note that parallel programming is currently mired deep in the swamps of #1; the simple threaded shared memory programming model is just loaded with connections. This implies that we're only going to get serious productivity improvements when we move to models with less connections.