Implementation Patterns
Though we have not found the silver bullet that would cure the software crisis by making programming teams vastly more productive, the last decade has seen a tremendous revolution in programming. The difference: while teams are only incrementally better, individual programmers can do vastly more. The largest programs that we can write have only grown modestly, but the largest programs that one or two people can write -- which is to say, the largest programs that an individual can understand -- have grown dramatically.
The kind of program that was a stunning achievement in 1967 -- a solid and efficient interpreter for an interesting new language, say -- was still a solid MA thesis in 1987. Today, we give that project to the summer intern.
The way this was expected to work was that programming languages would improve, gaining bigger and better abstractions so that programmers could avoid all that detail. The way this worked in practice, though, was not quite what we expected: languages did improve, to be sure, but the key change is that people mastered a new style of programming. It's not just object-oriented programming; it's small methods on small objects.
Right now, about half my readers are scratching their heads because they're expert programmers themselves and they have no idea what I'm talking about. Small methods?
If you're in this crowd, go to your bookshelf and grab your copy of that wonderful collections of Software Tools
Now, open it to a random page — say, something in chapter 5. Read the code examples. Try to resist the impulse to refactor — to simplify the conditionals, isolate the loop bodies, clarify the iteration. If you came across this in code you were working on, you'd say, "there are Code Smells here." But this is monumentally fine code — the very best of 1981.
Want to cry? Grab volume 1 of Knuth. Open it to p. 264: topological sort. If you're like me, you learned about topological sort right here. (Toplogical sorting is what we do when we've got a path of links in a hypertext and we want to unroll them into some sort of a sequence; it's what happens in Path View in Storyspace and Tinderbox and I've written it a dozen times over the years). You won't be able to read the code. This used to be a model of clarity; now, it's like reading the Latin you learned in school and haven't touched since.
Kent Beck is one of the leading voices on the subject of small methods programming. Much of his work is situated in the context of methodologies for programming teams, Extreme Programming and Test Driven Development. This volume is all about coding: writing clear and sensible code to do what you want. It's the clearest explanation of small methods style I've seen.
Small methods programming is especially well suited to NeoVictorian Computing, because it assumes that the coder is free to design and refactor objects on the fly. Small methods, in the end, mean that you have to give developers a lot of design autonomy, so your design has to emerge from the hand of the artisan, rather than having it imposed by the grand architect or the design committee.