With the subtitle "A Novel about IT, DevOps, and Helping Your Business Win" is this something every programmer should read?

I was looking for some anecdotal stories on software development when I found this book. The book is not really about software development. Rather the theme is to introduce the concept of DevOps which seems a little dated. Still, I decided to read it as fictional stories on Information Technology are difficult to find.

Well, I was pleasantly surprised. It was an entertaining read in the beginning. I could identify interesting characters that developers often have to deal with, more so if you need to attend management meetings.

Another thing, this is the first fictional book I read that tells the story in present tense. I don't really like that. Had it been regular fiction, I would have stopped reading. But I was curious about the subject and decided to continue reading. Surprisingly, after first few pages, I had no problem adjusting to this type of narration.

The book tells the story of a company that does not have IT as its core business. The story is told in first person by Bill Palmer, a manager in IT Operations, recently promoted to VP.

The story begins with an interesting exchange between Bill and the CEO along with a brief history of each of them. Actually, the developers take a back seat in this book, the hero being Bill, from the IT Operations department. An interesting drama unfolds on the chaos that results due to overwork and miscommunication between various departments within IT itself--operations, development and information security. You get a glimpse into the earlier era of non-systematic approach to prioritize, develop and deploy software. 

Various incidents in the story involve mismanagement of change handling, communication problems between departments, politics, and ego-clashes. If you have spent at least a decade in IT, the first part of the book will certainly touch a nerve, reminding you of the over-work of an all-nighter kind. On the other hand, if you have never worked in such a company, it's a sort of vicarious enjoyment to be part of all those scenes.

But here is something I didn't like. The initial part is too long before the interesting chapter with the first solution appears. The initial part should have been just a few chapters. The chapter in which the solution is introduced is quite engaging. A senior board member with a vast experience in manufacturing appears on the scene. The subtle way in which he takes Bill on a manufacturing plant visit to show similarity of Bill's IT problems with manufacturing is really fascinating. This is the part where the book shines. The interaction is quite like that between a wizard and a disciple that you see in fiction. Take for instance, the classic interaction between Master Shifu and Kung Fu Panda. In fact, the book makes references to the movie and that must have been the driving idea to tell the story in a dramatic way. Here the manufacturing concepts like constraints and flow of material are presented in an engaging, allegorical way. To make the things more interesting and introspective, the wizard does not straightaway give the solutions to Bill but rather, presents challenges in the form of key questions that need to be answered first. This is definitely the best part of the book.

Now comes the bad part. I thought the rest of the book would keep up this tempo of interesting parables and revelations. But here, the book falters and again plunges into a world of new problems and chaos. This is boring and could have been avoided. The second description of problems could have been kept short, to the point, quickly proceeding to explain the rest of the principles from manufacturing, referred to as “three-ways” in the book. They are--how to maximize flow of work, how to use feedback to improve the value stream and prevent problems, and how to take risks while constantly learning from success and failure. There are interesting and practical details on how these principles systematically expand and apply to Information Technology.

The end result of the excessive problem description in the second part was that the tempo built up by the fist solution was interrupted. I had to skim through the second part of the book, trying to locate the more interesting, wizard-like portions that introduce a new concept. Moreover, because so much time was spent on dramatizing the new problems in the second half, the end of the book sort of hurried through the solutions and through the dramatic recovery of the company at an unrealistic pace.

All in all, although too long, the book is worth reading for anyone in the field of IT, more so if you have been part of a project that failed. The book is admirable as a work of fiction that tries to explain manufacturing principles as applicable to IT in an engaging way.

Those who have worked in IT in the last decade and already familiar with the concepts of cloud computing, agile development, continuous deployment and more may not identify with the problems described. But they may still read the book, perhaps to get a feel for the problems that appeared in those earlier ways of software development and deployment, that too in an easy to read, fictional narrative.

To keep up with our coverage of books for programmers, follow @bookwatchiprog on Twitter or subscribe to I Programmer's Books RSS feed for each day's new addition to Book Watch and for new reviews.