Read The Dinossaurs!

I just finished reading a review for The Mythical Man-Month on Jaco Pretorius blog. This post started as a comment there but... you know how it works.

I would recommend to read his review in full, but here are the parts which caught my attention:

Apart from the examples being so outdated I’ve only really heard of one or two of them (in history books), the entire book reads like a dinosaur. [...]

So apart from the examples being from the stone age and the diction being long-winded, I tried to take a step back and consider why the concepts being discussed seem out of place.

It comes down to Agile development. Pretty much all the concepts and possible solutions introduced are superseded in one way or another by Agile. [...]

This book seems to advocate the incredibly outdated software life-cycle [...] Those days are behind us (hopefully).

I realize that at the time this book was written this was pretty much standard practice, I simply fail to see how it still has any relevance today. [...]

To be fair, some of the later chapters are a bit more modern [...] but arguing about whether or not Ada will be the next big programming language and whether or not Object-Orientated Programming will become mainstream really doesn’t appeal to me. Software development is simply a field which changes too quickly – a book which was written 10 years ago would be completely out of date, never mind one which was written 36 years ago!

I think a large part of the popular appeal of this book is unfortunately simply the nostalgia value. From a practical and relevancy perspective it offers very little.

If you follow this blog, you probably expect me to have some strong opinions about the points Jaco raises, as I am a bit of a book worm myself.

Disclaimer: I don't know Jaco; everything I write here is based on my interpretation of the review he posted and my assumptions can be just plain wrong.

It's about the mindset

It seems to me that much of Jaco's reaction is not to the ideas contained in the book, but to the "old" feeling of everything.

I used to buy a lot of books on technology. At some stage I gave up and decided that for frameworks, languages and tools I would read the book on the (excellent) Safari Books Online. I would only buy books where technology was used as a medium, not the goal. It's like the old, often misquoted as Dijkstra's, quote:

We need to do away with the myth that computer science is about computers. Computer science is no more about computers than astronomy is about telescopes, biology is about microscopes or chemistry is about beakers and test tubes. Science is not about tools, it is about how we use them and what we find out when we do.

—Michael R. Fellows and Ian Parberr, SIGACT trying to get children excited about CS

Many of the most important books for both computer science and software engineering use "outdated" technology (e.g. SICP, TAOCP, Refactoring, OOSC, Object-Oriented Heuristics, GOF's Patterns, POEAA...) and they are still relevant because the good ideas are still applicable.

Jaco asks a commenter to provide specific examples of how Brooks' essays originated many of the practices in this industry; I would be surprised if I find a recent book on software management that doesn't base its content on Brooks' work, even if transitively.

It is surely much more pragmatic to read a book with "Agile something" on the cover, drinking from the derived work. This is good enough for most practitioners.

If you don't understand what the situation was before that, though, agile becomes just another cargo cult (I'd say it's been one for quite a while). Knowing where our techniques come from is not nostalgia, it's History.

But I can see how people get frustrated with old, "classic" material. Authors use their current environment to illustrate how to apply the principles they had in mind. Some literature, like the Agile Manifesto and its practices try to be smarter by not mentioning specific technology; but this is not the norm; even for books published today.

There is always plenty of demand for books using some technology, even if the actual content is just recycled. In 2002, Uncle Bob released a book called "Agile Software Development, Principles, Patterns, and Practices". I found it great, and when Amazon recommended me what looked like a new edition of it I placed my order immeditaly.

What i didn't realise until I got my copy was that it has pretty much no difference to the first edition. The ideas, patterns... all important stuff was just the same, except that they used another language in the examples.

I surely prefer what was done with Domain-Driven Design. The book itself uses Java to illustrate its ideas, but it doesn't use more than the basic features of a class-based object system. Some authors then published books mapping the ideas to actual technology stacks, like 'enterprise' Java and .Net.

Outdated? Really?

Jaco works for ThoughtWorks. I was with them for four years (I don't think we overlapped), and a lot of my time there was spent on recruitment.

One day, I was interviewing a candidate for a development position. He submitted his answer to the coding challenge in JavaScript, and I was interested in how he coordinated multiple events happening on the browser window --it was a very nice animation.

As he was speaking, the technique sounded familiar and I asked a tricky question: "Sounds cool; did you invent this?"

He was young and never did anything that wasn't JavaScript before, so I expected to hear a proud yes. I was surprised when he said "Oh, not at all. This is the kinda stuff they used in old video-games". What he had was, essentially, a port of a very old-school, single-threaded game loop.

Outdated techniques may not be useful in our mainstream enterprisey world, but a good developer needs to learn about them so that they can at least know what to Google for. The limitations of browsers, mobile devices, big data platforms and so many cool tech are not that different from the limitations previous generations had to deal with. Again, it's History and you either learn from it or repeat the same mistakes.

Different opinions are good

Fred Brooks released a new book recently, it got a lot of attention back then and I read it as soon ad it was out.

I think people will be disappointed to know that his opinions haven't changed much over the past decades. It is still very much based on engineering and architecture (Brooks is an amateur architect). I am very sure that this has to do with the fact that Brooks is not like most of us, working for a company writing web apps. His perception of the field is different. That doesn't mean, though, that I cannot learn from him. His words on design consistency and trade-offs are really inspiring.

We talked about this topic a while back and, as I said then, I try to not let my limited vision of the development world get in the way when I am reading a text by someone who doesn't share the same tiny corner with me.

I never engineered a computer architecture or wrote an operating system. No software developed by my teams was ever considered "to be one of the most successful computers in history, influencing computer design for years to come"; so when someone on his position writes something I am eager to read it; even if it is not directly applicable to my current situation.