Paul Grenyer

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...

The Elements of Programming Style by Brian W. Kernighan and P. J. Plauger is one of those books that makes some excellent points that every software engineer should know and bear in mind every day. The central message is simple: write clearly and don’t be too clever. Say what you mean, use the language’s good features, choose names that won’t be confused, and structure your code so that its intent is obvious. There is plenty here that still feels completely relevant, including modularisation, encapsulation, keeping modules focused on one thing, making coupling visible, defensive programming and, perhaps most importantly, not stopping with your first draft. The advice to revise and refactor rather than being satisfied with code that merely works is something that could be written today. The chapters on efficiency and documentation particularly stood out to me. The authors make the point that if a program doesn’t work, it doesn’t matter how fast it runs, and that you should make it right...

Not Like That! How to build the wrong thing on purpose instead of the right thing by accident by Adam L. Coombes I really like this book. It’s divided into seven-minute chapters, which I found particularly effective. They’re short enough that you can get through one whenever you have a few minutes, but there’s enough in each one to give you something to think about. The writing is engaging and amusing too, which makes what could otherwise be quite a dry subject surprisingly easy to read. At first, I thought the author had misunderstood Agile. The early chapters seemed to be making the argument that Agile had somehow become a rigid process, and that we had forgotten the importance of actually talking to the people who use the software. My immediate reaction was: wasn’t this what Agile was supposed to solve 25 years ago? There’s a chapter called Agile Just Made It Faster , and initially I thought this was where we were going to disagree. But I think I was wrong. The author isn’t really a...

For research for a blog post, I’m reading Computer Programming as an Art by Donald Knuth , a transcript of a presentation he gave in 1974 . This particular passage resonated with me, especially in light of the current state of software engineering: The field of "automatic programming" is one of the major areas of artificial intelligence research today. Its proponents would love to be able to give a lecture entitled "Computer Programming as an Artifact" (meaning that programming has become merely a relic of bygone days), because their aim is to create machines that write programs better than we can, given only the problem specification. Personally I don't think such a goal will ever be completely attained, but I do think that their research is extremely important, because everything we learn about programming helps us to improve our own artistry. In this sense we should continually be striving to transform every art into a science: in the process, we advance the...

Finishing a story is difficult. It’s even more difficult to do well. It’s practically impossible to finish a trilogy well. I think Dust finishes the Silo trilogy quite well. Dust is a surprisingly short book, given all the threads which need tying up and the mysteries which need explanations. Rather than concentrating on the main threads, it meanders quite a bit in a few places. About 80% though, it feels like there’s no way there’s room left to finish the story. I can’t help feeling there’s scope for so much more and that Howey either wanted to, or was encouraged to, bring it to a quick end. The threads all tie up, but there are just so many unanswered questions. Having said that, it’s a difficult book to put down throughout and I enjoyed it to the end.

I’ve given my Beyond the Code: Designing Services That Stand the Test of Time presentation a few times now. It started as a talk I put together for the ACCU Conference - which wasn’t accepted - and has evolved quite a bit as I’ve presented it to different audiences, and had conversations with people afterwards. The original idea was fairly simple. As software engineers, we spend a lot of time thinking about business logic. We think about the domain model and how to operate on it, the workflows, and the data. These things are obviously important, but a service is more than its business logic. The things around that logic matter too. How the code is structured. Where responsibilities live. How components communicate. How we expose functionality through APIs. How we deal with failures. How we observe what the system is doing. What we test, and how. These decisions can have a significant impact on how easy a service is to understand, maintain and change. Because while almost everything ab...