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