Skip to main content

Principles of Program Design - Don't do it.

Image
By

 This book is unlikely to be of interest, unless you’re interested in data processing programs written in COBOL. However, I was interested in optimisation and the origin of:

1. Don’t do it. 
2. Don’t do it yet.

So I was satisfied with that at least. There are ideas here which have survived rather better than the examples, such as keeping programs simple, avoiding GO TO where possible and making each component responsible for validating the data it passes on. But much of the book is firmly rooted in the sort of data processing systems it was written for, and I struggled to relate many of the design techniques, particularly program inversion, to the way I think about software today. I did enjoy the occasional bit of personality, especially “A Moral Tale” and warnings to “resist this satanic temptation”.

The exception was the chapter on optimisation, which was by far the most interesting part of the book. Jackson’s two rules are wonderfully simple: “Don’t do it” and “Don’t do it yet.” His argument is that optimisation needs a positive, quantified justification and should only be attempted once you have a clear, simple and unoptimised solution. Making software faster or smaller can also make it harder to understand, maintain and change, and more prone to error. Nearly fifty years later, that still feels entirely relevant. I also liked his point that “optimization” is really the wrong word: making something faster or smaller does not necessarily make it better.

There was one final curiosity about my copy. It was printed in Great Britain by Page Bros (Norwich) Ltd in 1981, in my home town. Despite that, more than forty years later I had to have my copy shipped back across the Atlantic from the US. That was probably more interesting to me than quite a lot of the book. Principles of Program Design is an interesting historical artifact, and I’m glad I found the source of the optimisation rules I was looking for, but beyond that there wasn’t much here for me.

Principles of Program Design
M. A. Jackson
ISBN: 0 12 379050 6


Comments

Post a Comment

Popular posts from this blog

It's great to be back at the ACCU Conference 2025!

By
Last week I was back at the ACCU Conference in Bristol, for the first time since I gave an opening keynote in 2019 . In March 2020, COVID hit the UK and I got out of the habit of attending and speaking at conferences. Plus the ACCU Conference, and the organisation in general, took a big step back towards C++ and that hasn’t been relevant to me for nearly two decades. It’s taken until now, 2025 for me to want to talk again, and I was really pleased to be accepted for the ACCU Conference again. It was just a 20 minute session and I only attended for the day I was speaking. There was enough varied content for it to be interesting to me and I’m hoping to be back for the full conference next year. I really enjoyed attending and it was great to catch up with people I hadn’t seen for years. I felt re-engaged and particularly liked being asked if I’d been to nor(DEV):con . Learning to stop writing code (and why you won't miss it) Daisy Hollman I should have read the summary of the openin...
1 comment
Read more

I, Robot

By
The Foundation series has been my go to for a good, enjoyable read over the last two years, so naturally I moved on to Asimov’s Robot series afterwards. However, the short stories in I, Robot were mostly a disappointment. They feel self indulgent, with too much philosophy and science, Asimov showing off, and not enough story. The most enjoyable moments come from the stories featuring Gregory Powell and Mike Donovan. Their banter and the relationship between them provide some much needed amusement and were easily the highlight of the book for me. However, it did give me food for thought for the current potential issues with the rapid development of AI at the moment, and the many concerns around safety. I wonder if all we need is: An AI may not injure a human being or, through inaction, allow a human being to come to harm. An AI must obey the orders given it by human beings except where such orders would conflict with the First Law. An AI must protect its own existence as long as such p...
1 comment
Read more

Write Your Own Load Balancer: A worked Example

By
I was out walking with a techie friend of mine I’d not seen for a while and he asked me if I’d written anything recently. I hadn’t, other than an article on data sharing a few months before and I realised I was missing it. Well, not the writing itself, but the end result. In the last few weeks, another friend of mine, John Cricket , has been setting weekly code challenges via linkedin and his new website, https://codingchallenges.fyi/ . They were all quite interesting, but one in particular on writing load balancers appealed, so I thought I’d kill two birds with one stone and write up a worked example. You’ll find my worked example below. The challenge itself is italics and voice is that of John Crickets. The Coding Challenge https://codingchallenges.fyi/challenges/challenge-load-balancer/ Write Your Own Load Balancer This challenge is to build your own application layer load balancer. A load balancer sits in front of a group of servers and routes client requests across all of the serv...
Post a Comment
Read more