Welcome

Welcome to the Art of Computer Programming. I am Per Lundholm and ArtComputer is my company. I have been a professional programmer for 40 years and here is what I have come to believe on the subject.

I will speak about craftsmanship, architecture and people. I will speak about Readability, Refactoring, Retrospectives, Resources, Responsibility, Respect.

Craftsmanship

Programming is a craft. We do not create the same piece of software over and over again. Each time we solve a new problem. We like to look at well crafted code but we have different opinions on what "well crafted" means.

The first thing about craftsmanship is refactoring. Code is never well written on first attempt. We simply can not just sit down and type well crafted code from scratch. If we could, we would not be solving anything complicated. Instead, we learn about the problem as we go. Therefore, to create well crafted code, you need to refactor it. You can not simply stop because you got it working.

Refactoring

When you refactor, you change the code without changing its behaviour. To guarantee that, you need to have tests that will tell you when your changes break the code. Tests shall also be well crafted, of course. Serving as a specification, they should not be coupled to the implementation.

Tests serve two purposes, to verify that the code works and to specify the intended behaviour. Thus, even simple code needs tests.

When your code pass the tests, you can start looking at readability. Never be proud of being able to read cryptic code, be proud of writing code that reads like running water. I have written 7 rules on code readability which you may enjoy but there are more sources out there.

Your attitude is important, never stop until your code is readable.

Once the code is readable, you can refactor it further to become minimal. But never on the expense of loosing its readability.

Responsibility

As a professional programmer, you are obliged to take responsibility for your actions. Bad code can kill people or loose large amounts of money.

You are responsible for all the code you write.
You are also responsible for code that you should have written but neglected to. E.g. tests, logging, monitoring
If you feel you don't have time to do a proper job, it is your responsibility to plan better.
If you have neglected your training so that your code is not the best, it is your responsibility too.
If other people writes bad code, it is your responsibility to help them become better through carefully written comments in code reviews, pair programming, mob programming or what other means you can find.
If requirements or whatever you base your design on, is incomplete or inconsistent, it is your responsibility to sort it out. You are responsible to know the domain you are working in.

Respect

You should always treat other programmers with respect, you have no idea what their background is. Criticise behaviour or code but never a person. When you think something is not right, speak out of consequences. Eg "Unless we have tests, changing things such as a new version of a framework that we use, may break our code without us knowing it."

You should always respect the users of your software. If they can't use your system, it is a bug.

See this post that I wrote on how to define bugs.

User respect is about understanding their situation when they use your system. Their mental model of the system is most probably different from yours. That is one reasons your naming of things must be constantly updated to stay in sync with your users' world. Mind the gap, if you see what I mean.

Organisation

Your software is connected to how its owning organisation communicates, it is Conway's law. Amusing observation at first, but then you realise how painful it can be. It actually tells you that you can not redesign your system architecture without changing the organisation, and vice versa. Once you have established a working system, you have a hard time to innovate. Perhaps that is why Apple changed on how we look at mobile phones and Tesla changed the car industry. Neither were established and stuck with that law.

For us doing software, it is a problem when projects cross several systems because we need a little something changed in each of those systems. It is today called "component teams" as they are organised according to components, strictly following the system architecture. Thus a project will engage a lot of people which means a lot of communication and synchronization. Expensive and error-prone.

Software Architecture

This is without doubt a large subject. It is also debatable what it really is. All systems have structures of different kinds, such as how data flows and nodes. These structures affect the system's qualities, such as security and performance. If you search the internet, you'll find many sets of qualities to look for. Let me give you one set by the acronym STAMPUS.

STAMPUS stands for Security, Testability, Availability, Modifiability, Performance, Usability and Scalability. What you might observe is that many ends with "-ility", which makes many speak of "ilities" as qualities.

You can read my blog post on why do we never get the time to work on system architecture to find short explanations on these attributes.

Thanks for taking your time to read this. Click on the clock for a full screen version. Note that some browser may not reveal your time zone, so you may get the UTC version.