1 Comment

Agile Development & the History of the Mac

I’ve been reading the articles on the birth of Apple’s Macintosh at folklore.org recently. Folklore.org’s purpose is collective historical storytelling accomplished through the anecdotes of multiple contributors. Only the development of the Mac is presently chronicled. The reading is wonderfully interesting and engaging; it’s like a book I can’t put down.

Atomic Object’s history is intimately linked with eXtreme Programming (XP). These days XP is probably better known under the larger umbrella of Agile methodologies. XP was inspired by successful practices observed at work throughout the history of software development. In reading about the first Mac I’ve been encountering examples of processes and techniques that are quite familiar; perhaps these stories are similar to those that inspired XP.

XP has an unfortunate name. Software is difficult enough to get right; labeling a development methodology as “extreme” probably hasn’t helped its adoption. However, XP’s name comes from sound thinking. The originators of XP looked back over software development’s relatively short history to identify practices that cost effectively produce high quality software. 13 practices were identified and then the question was asked – if a little of these practices is good, what would happen if they were cranked up to the extreme?

In reading the stories of the Mac’s development, I’ve noticed several of XP’s themes, practices, and techniques played out in the historical narrative. Sure. Some of the connections I’ve made are almost certainly a stretch. My perception is no doubt influenced by my support of XP/Agile, and I’m probably shoehorning the Mac’s history into an XP shoe. Still, I see the underpinnings of XP/Agile at work here. I have to think that the revolutionary Mac was a success in part because of how it was developed. If nothing else, the following is enjoyable reading.

  • A few paragraphs towards the middle of “The Macintosh Spirit” demonstrate the value of iterative development; in fact, one of the anecdotes has inspired me to research Agile hardware development techniques for embedded systems (more in a later post).
  • -2000 Lines of Code” is an amusing example of the value of refactoring.
  • Calculator Construction Set” illustrates including the customer (or in this case a proxy) as part of the whole team.
  • Rosing’s Rascals” details the value of spikes to try implementing tricky software features before committing to them.
  • Do It” is a (humorous) take on the value of exploratory testing and involving end users in testing.
  • The Grand Unified Model (1) – Resources” is a good example of how valuable metaphor can be to development.

Sadly, I haven’t come across any stories that could be construed to demonstrate Test-Driven Development.