Writing software should be treated as a creative activity. Just think about it – the software that’s interesting to make is software that hasn’t been made before. Most other engineering disciplines are about building things that have been built before. People say, “Well, how come we can’t build software the way we build bridges?” The answer is that we’ve been building bridges for thousands of years, and while we can make incremental improvements to bridges, the fact is that every bridge is like some other bridge that’s been built. Someone says, “Oh, let’s build a bridge across this river. The river is this wide, it’s this deep, it’s got to carry this load. It’s for cars, pedestrians, or trains, so it will be kind of like this one or that one.” They can know the category of bridge they’re building, so they can zero in on the design pretty quickly. They don’t have to reinvent the wheel….
So, because you can program well or poorly, and because most of it is creative (in that we don’t really know what we’re doing when we start out), my view is that we should train developers the way we train creative people like poets and artists. People may say,“Well, that sounds really nuts.” But what do people do when they’re being trained, for example, to get a Master of Fine Arts in poetry? They study great works of poetry. Do we do that in our software engineering disciplines? No. You don’t look at the source code for great pieces of software. Or look at the architecture of great pieces of software. You don’t look at their design. You don’t study the lives of great software designers. So, you don’t study the literature of the thing you’re trying to build.
I was particularly intrigued by the parallel Gabriel draws between studying a body of existing literature in poetry and studying examples in programming. In my limited experience of studying programming there are lots of examples to be found that tackle small problems, solutions or modules that take a few hours or days, at most, to figure out. Students write reasonably large projects as part of their classwork but they rarely read the large projects of others. I’m reminded of work on literate programming. Gabriel’s work on the Feyerabend Project also intrigues.