A New Metaphore - Epic Story to TV Series

I’m currently reading a book by Ka Wai Cheung called “The Developer’s Code: What Real Programmers Do”. In the chapter called “Metaphor” Cheung writes “...when I’m asked what I do, I often resort to analogy. Our industry is chock-full of them. It’s the way we describe our work to everyone else... metaphor has to become our meta-language. Not only is it how we connect the uniqueness of programming to the general public, but it’s often how we make decisions on how we approach our own software problems.” He goes on to explain how we borrow from traditional building when we speak of building software. We have roles such as engineers, architects, project managers and designers. We have borrowed our very identities from another industry. Some of that made a lot of sense when software releases were done over floppy disk or CD, but not today with the web the way it is. I wont quote the entire chapter, but he ends with the idea that, “Software development might be closer to writing a novel or composing music.” I love the writer analogy and I’ll probably overuse it so much in the future that it will become more harmful than helpful, but let’s have some fun with it.

There is a series of fictional books out by one of my favorite authors. Perhaps you have heard of George R. R. Martin, or perhaps you have heard of the HBO series that is based on his books called, “A Game of Thrones”. It has a very mature rating so be warned if you check it out. My new analogy for software developers and software projects in general is that of the epic book series turned TV series. Writers (Developers) take the original book (Business Processes) with the help of the director (Architects or Leads) and the original author (The Business), and they break it up into seasons and episodes. For now I like to think of the season as the current technologies a project will take advantage of. Each episode is a release with it’s minimum marketable features and these can and should happen much more often than we have allowed them to in the past. As Cheung says, we are on the web and people are now embracing iterative change much more than they use to. In all episodes there are lots of subplots or stories that make up the whole episode. Agile has already defined features as stories, so I’ll just stick with that for now.

Before I read this book and before this analogy, I started calling our sessions by season and episode (S3E2). It was just my funny way of keeping things interesting but now I’m going to rethink the significance of it. I think this is a way better description of our industry today than the bridge or skyscraper analogies of days gone by and as Brian and I co-author Luncht I’ll be thinking about it more and more.