One thing that I have enjoyed in the working world, but have had precious little of during my software education is history.

In many fields the focus is either on teaching the formulas or the history; Mechanical engineering focuses heavily on formulas, all the history has been distilled into concise representations. In other fields the focus is on learning from historical examples, economics is a good example of this where stories are used to illustrate principals.

In software I received neither, even in my further education in looking at training trough IASA or other certifications there does not seem to be a focus about learning from the past. There is a drive to try and form software into formulas, and there are people who approach creating the formulas from the past (http://www.construx.com/File.ashx?cid=2868) but there is no focus on storytelling of projects past.

There are some natural reasons for this; we assume that anything done 10 years ago could not possibly be applicable to current day technologies. In a field that believes that technology moves faster than in any other field it is hard to explain that history has value. It is also hard to actually find out about the information, sure there are some (in)famous projects but when compared to the sheer number of development efforts undertaken it is hard to imagine that anyone would even be aware of 1% of the efforts. And lastly a failure has to be amazingly spectacular before anyone would ever hear of it. In general the only failures that are heard of are those that in some way manage to get into production or have a lot of early promotion. Daikatana (http://en.wikipedia.org/wiki/Daikatana), Duke Nukem Forever (http://en.wikipedia.org/wiki/Development_of_Duke_Nukem_Forever); but there is very little information on business efforts that have gone horribly awry.

The only historical development stories that I read in college was in The Mythical Man-month (http://en.wikipedia.org/wiki/The_Mythical_Man-Month) it had some tales from IBM development on mainframe systems. Projects that went over budget, were late and brought up to sell a principal as to why this happened. But that was all.

Maybe software development would be better off if there was a bigger focus on storytelling, a focus in learning about great and small efforts that happened in the past. This could help students in developing a repertoire of stories to tell around the water cooler and find parallels between their challenges and the past. This may seem like a somewhat trivial skill to develop but it ends up being essential in execution.

Storytelling can help teach other people the nature of problems; the ability to abstract an issue from your current reality into a tale allows people to see the problem in isolation. When people can see the problem, and recognize the problem in their own reality, they will be receptive to solutions. For example, in College you will learn about unit testing, in the professional world you will notice that adoption of this practice is … not very good. If your company has a quality issue then you have knowledge that unit testing is something that can alleviate quality problems. But what you have not learned is how to move to that, what exact types of problems can be attacked this way or offer people a real world sample of this process working and/or failing.

The history of software development might prove a more useful guide to the future than is assumed; and there might be value in starting to compile these works into a body of knowledge. Once this exists there can be a generation that can learn from the past due to studying the past. Jumping past history to extrapolated formulas makes the results ring hollow and hinders adoption.