I’m currently reading Code Complete, the software engineering book I have had recommended to me most often. It’s good, although like many of these books it makes me feel guilty about some of the sloppy practices I currently engage in.
I was just struck by a passage from the design chapter, talking about how requirements and an understanding of the problem changes as development proceeds. In particular, it addresses “wicked” problems, where the problem only becomes really apparent after a first solution has failed to solve it. The example is the famous Tacoma narrows bridge, where the designers did not realise wind across the bridge would cause a destructive harmonic ripple; the problem was not adequately specified until they had a solution that did not solve it.
The passage reads like this:
One of the main differences between programs you develop in school and those you develop as a professional is that the design problems solved by school programs are rarely, if ever, wicked. Programming assignments in school are devised to move you in a beeline from beginning to end. You’d probably want to tar and feather a teacher who gave you a programming assignment, then changed the assignment as soon as you finished the design, and then changed it again just a as you were about to turn in the completed program. But that very process is an everyday reality in professional programming.
It sure is. Shouldn’t we be teaching that?
Peter Saffrey's Weblog 
Leave a comment