Year ago, I read a book on time management (or procrastination) called “Eat That Frog!”.

In the book the author, Brian Tracy, proposes that you should always tackle the most challenging task on your To Do list first.

Now I have not applied that principle in my life, but I have certainly applied it in my programming.

The first thing you should tackle when writing a program is always the part about which you are most unsure, or the part which the most risky.

It’s amazing how often I have asked a programmer “how did you get on with X” and they reply that they haven’t got to it yet because they decided to start with Y. And Y is often something which involves no risk at all (like settings, configuration, admin screens, or even a splash screen!)

Example

When I was working on the COVID program recently, I started with the things with which I was least familiar: the HTTP Client class first and then the JSON library. Once I got these working, then I knew that everything else would fall into place quite easily.

Conclusion

When you start a new program, always start with the piece which scares you most. Don’t waste days doing the easy stuff before discovering that there really is a problem with that scary piece.

You often hear stories of programmers who work best in the evening or at night, or programmers who “pulled an all-nighter”.

I take a different approach.

When I am struggling with a piece of code (a bug I cannot track down, for example) I call it a day and sleep on it. I am still amazing at how often I find that I will awaken with a solution.

They say that the following happened in dreams:

• Dmitry Mendeleyev came up with the periodic table of elements
• Dr. James Watson came up with the double helix structure for DNA .

Now I have never done anything as earth-shattering, but here are two recent examples from me.

Example One

I wrote a COVID-19 app recently and I was struggling with the HTTP Client class which I was using to interact with the API to get the data.  The documentation for the class was pretty light and I could not find any sample code. The problem I was having was specifically in relation to the callback function.

I was having so many problems that I decided to try the Websocket Client class instead. I was struggling with this too.

But when I woke up the next day I was sure that I could get the HTTP Client to work without using a callback and that is exactly what I did and it worked for me.

Example Two

My daughter was doing a project for her university course which involved designing the hardware and software for a networked automatic hand sanitiser dispenser. I wrote some pseudocode for the software which monitored the proximity sensors and the liquid levels.

The code had a check for thresholds on the liquid levels and could send alerts as these thresholds were passed.

I realised that there might be an issue where (due to slight fluctuations in the readings) the liquid level might seem to cross back and forth over a threshold and this would trigger multiple alerts.

Since this was just pseudocode for a project which would never by built, I decided not to worry about it.

But when I woke up the next day I realised that a simple tweak would fix this.

So now when I get a new reading, I check it see if it is greater then the previous reading. If so, I check to see if the increase is about a configurable threshold (min_increase). If it is not greater then min_increase, then I just set the new reading to be the same as the previous reading. Job done!

Conclusion

If you are struggling with a design or coding problem then try sleeping on the problem.

The first two principles for good programming were Simplicity and Elegance.

But there are not independent. The aim must be to write code which is as simple and elegant as possible, while getting the job done.

Shibumi is a concept I came across in the book of the same name, written by Rodney Whitaker in 1979 under the pen name of Trevanian. I mentioned this book (which is my all-time favourite) in my old blog.

It is a Japanese word with a number of meanings, including “elegant simplicity”. Here is a passage from the book:

Shibumi has to do with great refinement underlying commonplace appearances. It is a statement so correct that it does not have to be bold, so poignant it does not have to be pretty, so true it does not have to be real. Shibumi is understanding, rather than knowledge. Eloquent silence. In demeanor, it is modesty without pudency. In art, where the spirit of shibumi takes the form of sabi, it is elegant simplicity, articulate brevity

When Nicholai Hel (the hero of the book) heard these words, he decided to dedicate his life to achieving Shibumi.

I’m afraid I have not dedicated my life to Shibumi, but I do look for Shibumi when I am programming.

In programming, Shibumi is thinking about a problem until a simple elegant solution is uncovered, and then coding accordingly. Whenever your design or code seems complex or convoluted, you need to do some more thinking.

Programming is an art, not a science. Some people might baulk at the idea that it’s an art, but it is certainly a craft.

Bad programmers write bad code, great programmer write elegant code.

I have read a lot of code in my time. And some of it was so badly written that it was scary.

Conversely, it is a pleasure to read code that is so well-written that it is elegant.

Writing a program involves making dozens (or hundreds) of decisions. It involves solving lots and lots of puzzles.  Solving puzzles is one of the great joys of programming. There always multiple ways to tackle each puzzle. And each decision is an opportunity to move towards elegance, or towards chaos.

I don’t think everyone can be a good programmer. I have worked with people who wrote chaotic code. This code was a nightmare to read, and a nightmare to maintain/enhance.

Some people have the gift of finding the elegance, and some do not. That’s what separates bad programmers, from good programmers, from great programmers.

In my opinion, a great programmer would not be happy just to get a program working. They would not be happy until the program is elegant.

I think it’s acceptable to write a small piece of inelegant code while you’re trying to get something working, or to understand it fully. But once you have that clear picture, you should always rewrite/refactor for elegance.

A simple example of the decisions which a programmer needs to make is when functionality should be delivered inline, when it should be moved out to a separate function/method, and when a new Class is needed.

Elegant code should be easy to read and understand. Badly written code can be a nightmare to understand!

First Example

I have a book called “Java Examples in a Nutshell” (written by David Flanagan) which I cannot throw out (even though it is dated – my edition was written in 1997) because the code is so elegant. Each of the programs is as simple as possible, while illustrating the technique in question. Almost all of them have a “main” method and most of them process simple argument so that they can be called from the command line.  One, for example, is called “SimpleProxyServer” and it illustrates a simple web proxy which has one thread for passing on outgoing content, and another for passing on incoming traffic.

Second Example

This is a link to some Java code which implements the Asteroids game as a Java Applet (it was written a long time ago!)

It is a very faithful recreation of the original game and I think the code (although there is quite a lot of it) is very nicely written and very easy to read.

The main look contains the following:

updateShip();
updatePhotons();
updateUfo();
updateMissle();
updateAsteroids();
updateExplosions();

Makes sense right?!

Aside from the main Class, there is only one other one: “AsteroidsSprite”. This is used to manage all of the “vector graphics”-style objects.

The Class has a method called “isColliding” which takes one argument which is another AsteroidsSprite. So you can easily ask any AsteroidsSprite if it is colliding with any other AsteroidsSprite. Simple as that.

And there is a method called “explode” which takes an AsteroidsSprite as an argument. It creates a set of AsteroidsSprites, one for each line in the original object. And then those  AsteroidsSprite are added to an array called “explosions” and those lines move and fade as they would have in the original game.

In the hands of a less capable programmer than Mike Hall this could have been a real mess. But it’s not. It is elegant.

Conclusion

The difference between a mediocre programmer and a great programmer is that the latter can make a series of decision which allow him/her to write elegant code.

KISS (or “Keep it Simple Stupid”) is a principle which was created in the 1960s apparently.

Certainly it was something we talked about when I started programming.

It is as true now as it was then.

Apparently Einstein said that ““Everything should be made as simple as possible, but no simpler.” He was a smart guy!

The trick in programming is to resist using something because it’s clever, or because it’s new, or because it’s trendy.

When something is simple, it easier to get right, it’s easier for others to understand, and it’s easier to maintain and enhance.

I have two stories to illustrate this: one new, and one very old.

First Story

The old one was when I was working in Shield Life and going to Trinity College in the evenings.

On my course I learned how you could create files where each record had a pointer to the next record (and optionally a pointer back to the previous record). So when you found the first record in a set, you would easily navigate to the others. And you could have another chain of free records which would could use when you needed to create a new record.

So we had a requirement for an “Outstanding Premium File” (OPF) which would store all of the premiums which made up an individual Direct Debit for the bank. Then if the Direct Debit was declined, you could work out which policies had not been paid so that you could take appropriate actions. I decided that this was a perfect use case for a file with record pointers.

I developed the program and it worked perfectly.

The problem was that, after I left the company, the team decided to re-develop the program using a more traditional approach which everyone could understand and maintain.

So I had ignored the KISS principle and I had developed something that other programmers did not like. I had been seduced by something that seemed to be very clever.

Story Two

The second story is recent. We were developing a solution using SharePoint Online, SPFx, Azure, etc. and the architect and developers decided to use a Term Set in SharePoint to hold data which could have been held in a lookup list.

I could not understand the purpose of using a Term Set for this. Term Sets have an important role to play in some circumstances. But to me it looked like complete overkill for a lookup field.

And it turned out that it introduced a number of unnecessary complexities:

• We needed to have separate term sets for test and production. Using lists, it would have been as simple as having two sites and independent lists in each.
• We had to add values to lists using PowerShell and these scripts were made more complex and more troublesome because they had to populate the term sets
• The client wanted to export the data to Excel. We used the native export at first. But the term set columns were weird when exported to Excel. In the end, we did a custom export.

Conclusion

Einstein was right: it’s best to keep everything as simple as possible, but no simpler

I have been developing software for a long time. And over those years, I have come up with an approach to programming and some basic principles.

These are now part of my “gut feeling” when I’m developing something new. But in the coming posts I am going to try to isolate, examine and document them.

I’m calling this series “Peter’s programming principles”. There are a couple of things to say about this:

• I could not resist the alliteration!
• I’m not sure when exactly “programming” became “software development”, when “programmers” became “software engineers”, and when “programs” became applications/apps. But I think the old names were just as good.

The principles are all high-level. They are about an approach. If I talk about a specific technology then it will only be to explain the principle.

The principles I am going to describe are:

• Simplicity
• Elegance
• Shibumi
• Sleep on it
• Difficult things first
• Layering
• Event-Driven
• Data-Driven