What Makes Good Program?

What makes a good program? It’s a tough question. We can have many metrics such as if it’s working, whether it meets specifications, or if it’s delivered on time, or if there is a possibility to do easy change, or if it’s efficient, and so on.

Personally, I would say it’s good when it works as it should. But opinions can vary between people. It’s a totally different experience to create a program for one, two, or millions of users. More people have more different needs, which leads to many conflicts.

Anyway, a good program from one point of view always has many problems from another point of view. There are many reasons, mostly some limitations such as a machine, language or programmer limitations, or some historical accidents, to name a few. Even the specification could be one of the problems.

Maybe we could try to define a good program the other way around. Let’s assume a good programmer creates a good program. What makes a good programmer? Well, it’s also hard to define. :-)

Is junior programmer bad? I wouldn’t say so. It’s definitely a bad situation when this programmer should work without leadership or with over-leading.

Or what is better, a slow programmer who hardly makes any mistake or a fast programmer who does error from time to time? It depends. It depends on the team. Usually, the team will benefit people with different capabilities to cover many tasks. Or more languages.

Speaking of languages, did you know that around 1970 there were about twenty new languages every year? Nothing much changed in 50 years, right? Only new platforms and languages were introduced. Old programmers could give to our “young dynamic collectives” many precious advises.

One of the advice could be that language itself is not essential. The critical part is the tooling around the language. This means even when the language or framework or system is not good (but who can say what is right and what isn’t ¯\_(ツ)_/¯), it does not imply that the program is not good as well. It only means it’s harder to maintain it. It can be harder to remember syntax or names or rules, which can bring more bugs.

Old programmers could tell you also about object-oriented and functional programming. No one knew it would be important. The concept itself is here for a very long time, but it took a lot of time to understand it and use it. Many languages implemented those techniques on different levels, and today we have many choices with different historical accidents.

That’s why I think to learn or even create new languages just because, is not a good idea. You need a lot of energy to learn to speak a new language or create again standard libraries. Let’s look at it like to a book. You don’t have to learn Latin (some very old language) or Esperanto (some new generic one meant to be the only one) to write a good book. The same is valid for a good program: you don’t have to learn fill your next language you think will solve all your problems.

I think I made my point that a good program is not defined by computer programmers at all. Computer programmers care mostly about tools that they like, not about the final product. What about the owner/client for whom we do that program? Such an owner has the interest to deliver the product as soon as possible with all the features from the specification to have something new to sell or use.

I will not discuss the details; it would be for very own long post, but trying to have always something new to sell is not good. I know that this is currently a leading economy. But it’s just wrong. I hate unnecessary things. I hate how a market works right now. It’s not healthy.

I know it’s not very objective. Let’s move to something else, specification. I never ever seen a precise final specification. Not from the client and not even from a product manager. The client never knows exactly what he or she wants. Many (not only) programmers, at least around me, hate the word agile. Maybe because at many places is used label agile to something that isn’t agile at all. I like to call it communication—just the plain communication between members of the team. The specification cannot be made, it has to be continuous communication to overcome all the already mentioned limits (machine, language, programmer), which are not known during the creation of the specification.

Which, kind of, implies that the time of delivery cannot be specified as well. Programming is not a race. For example, it’s stupid to try to find a bug as fast as possible. Actually, it’s the same as not trying at all. Again it’s similar to books. Even when you are the only one who writes the book, you cannot tell if you can make to write it in a year. Actually, developers are like writers. They write essays for computers, which then can make users happy…

That’s it! The better question would be: what makes a good program for users? What makes them happy?

From my point of view, a good program is when:

• It allows me to do what it’s meant for. Easily.
• It’s reasonably fast. I don’t have to wait for minutes just to see my e-mails.
• It’s reasonably big. I don’t have to download several megabytes to see contact information.
• It doesn’t distract me with many notifications. Definitely not with artificial notifications (Facebook, games, …).

And I think this is also a good description of what makes a good program.

And I think that also a good computer programmer is when he or she:

• Writes a program which can help me with my problem. Easily.
• Writes a reasonably fast program. It doesn’t have to be super optimized, but there is no unnecessary loop and so on.
• Writes a reasonably big program. It doesn’t have to be super small, but I don’t have to download all codes from NPM to see contact information.
• Writes a program without notifications like “there is a new view of your page” or “many players haven’t seen you for some time”.

Be a good computer programmer and write good programs. The world can be better. :-)