I keep coming across old books around software engineering that are hard to find online, and hard to find as ebooks too. I’ve tried to find a copy of ‘Structured Design - Fundamentals of a Discipline of Computer Program and Systems Design’ recently. It’s possible to get a used copy for £30 or so if you’re willing to wait, Amazon sells this book for a whopping £70. It was published in 1979 which blows my mind. I haven’t read it as it only got delivered today but I’ve had a flick through it. While the tech and the tools we use to get the job done change massively, the core principles behind software architecture really don’t seem to change a great deal at all.

There’s one quote in particular that caught my eye in this book:

There is not much point in talking about efficient systems or optimization if the system is being designed and/or programmed by people of only mediocre talent. Of course, this is a rather sensitive issue. One’s ego makes it difficult to deal with one’s own mediocrity, and one’s manners make it difficult to accuse colleagues of mediocrity. Nevertheless, it is a fact that should be faced squarely: A surprisingly large number of analyst / designers design stupid systems, and an even larger number of programmers write horribly stupid code.

These are blunt words, to be sure. However, a classic study by Sackman et al. pointed out that, among experienced programmers, we can find a 25:1 difference in design time and debugging time. Equally disturbing is the fact that the resulting code can vary in speed and size by a factor ten. The most depressing fact of all was that Sackman’s study indicated that there was no correlation between programming performance and scores on programming aptitude tests. H. L. Mencken observed that nobody ever went broke underestimating the intelligence of the American public. After visiting programming organizations around the country, the authors have concluded, somewhat sadly, that a similar statement could be made about programmers and designers.

Our point is simple: There is no substitute for competence. If you want a system designed and implemented efficiently, make sure it is done by people who know what they are doing — which, by the way, has very little to do with the number of years they have been working in the computer field!

There’s a big list of quotes here if you want to know more about the book: https://www.win.tue.nl/~wstomv/quotes/structured-design.html

You have to remember this is from 1979. 41 years ago, and yet, I can’t agree more that a surprisingly large number of developers are still designing very stupid systems with very stupid code. Well, I guess we all write stupid code. Rather, some of us refactor it and keep refactoring until it stops being stupid.

I started a project recently, and the beginning is always a bit scary. For me it always means a ton of refactoring. It’s not so much the tech that causes this most of the time but it can be a contributing factor. Instead, it’s the domain; the problem we’re solving is the initial cost for me. Learning about the product, why a certain feature needs to exist, analysing what is likely to change and what parts of the system belong together and which don’t.

You can’t get this stuff right at the beginning. It’s not about being right, but designing a codebase that can change and pivot in different directions at a low cost. In 2 weeks, I will know so much more than I do now about this project. It’s all about setting things up for the future where a ‘better’ version of me will always do a better job than my present self possibly could. The future me will almost always be better than where I am at now (with exceptions), so I must make things as easy on my future self as I can.

How do I try and write code that’s easy to change? I’m planning to do a blog post (or a series of them) on this with as much detail as I can put in. I got asked this question in an interview, and it’s very easy to jump straight to the ’low coupling high cohesion, SOLID principles’ typical kind of answer most would expect. What does that really mean day to day as a software developer, though? A lot of us know the theory but not enough of us put it into practice. Communicating how I practice this stuff is what I’d like to cover.

Another book that was a struggle to get hold of was ‘Pair Programming Illuminated’. I’ve got a used copy of it, and I’ve not come across a book that has dived into pair programming like this one has.

There are probably loads of these old books out there that are slowly disappearing, and many that have disappeared. If you know of any lesser-known books like this, then feel free to add a comment. I’m trying to collect as many of these books as I can before they disappear for good.