TITLE: Nothing From Scratch AUTHOR: Eugene Wallingford DATE: February 22, 2011 4:06 PM DESC: ----- BODY: Over the weekend, I enjoyed re-reading Brian Foote's The Craftsmen vs. the Scavengers, which is subtitled "The Ruminations of a Foot Soldier on the Reuse Revolution". Foote expressed an idea that has been visited and re-visited every so often in recent years:
In a world dominated by code reuse, all programming, will, in one sense, be maintenance programming.
Foote was a student of Ralph Johnson, who has written and spoken occasionally about the idea that software development is program transformation. I blogged about Ralph's idea and what it meant for me nearly five years ago, just before teaching an intro CS course that emphasized the modification and extension of existing code. Some people worry that if we don't start students off with writing their own code from scratch they won't really learn to program. Most of the students in that CS1 course have turned out to be pretty good programmers; that's just anecdote, of course, and not evidence that the approach is write or wrong. But at least I don't seem to have done them irreparable harm. This idea is comfortable to me as an old Smalltalk programmer. As Foote elaborates, the Smalltalk toolset supports this style of programming and, more importantly, the Smalltalk culture encouraged code reuse, sharing, and a sense of collective code ownership. We all felt we were in the same boat -- the same image -- together. The commingling of Foote's assertion and my recollection of that CS1 course caused my mind to wander down another path. What about those times when we do start with a blank slate on a new project? If we approach the task as programming from scratch, we might well design a complete solution and try to implement it as a single piece. When I do maintenance programming, I don't usually think that way, even when I have a major change to make to the program. I'm usually too scared to change too many things at once! Instead, I make a series of small changes to the code, coaxing and pruning the system toward the goal state. This is, I think, just what XP and TDD encourage us to do even when we code on a blank slate. It's an effective way to think about writing new programs. The very next section of Foote's paper also caused echoes in my mind. It suggest that, in a culture of reuse, bad design might drive out good design simply by being there first and attracting an audience. Good design takes a while to evolve, and by the time it matures a mediocre library or framework might already control the niche. This may have happened in some parts of the Smalltalk world, but I was lucky not to encounter it very often. Foote's idea comes across as another form Gresham's Law for software design, so long as we are willing to mangle the original sense of that term. The effect is similar: the world ends up trafficking in a substandard currency. It sobers me to note that Foote wrote this paper in the summer of 1989. These ideas aren't new and have been on the software world's mind since at least the shift to OOP began twenty-five years ago or so. There truly is nothing new for me to say. As a community, though, we revisit these ideas from different vantage points as we evolve. Perhaps we can come away with new understanding as a result. -----