What Makes Good Program?

en in code • 5 min read

What makes a good program? It’s a very hard question. We can have many metrics such as if it’s working, or if it meets specification, 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 user, for two or for millions of users. More people have more different needs which lead to many conflicts.

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

Maybe we could try to define good program the other way around. Let’s assume a good program is created by a good programmer. 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 does any mistake or a fast programmer who does mistake 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 important. The important part is the tooling around the language. Which means even when the language or framework or system is not good (but who can say what is good and what isn’t ¯\_(ツ)_/¯), it does not imply that the program is not good as well. It only implies 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 will 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 langauge) or Esperanto (some new generic one meant to be the only one) to write a good book. 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 progammers care mostly about tools which 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 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 clear 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 creation of the specification.

Which, kind of, imply 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, 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 minutes to just 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 artifical 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 unecesary 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 informations.
  • Writes a program without notifications like “there is a new view of your page” or “many players haven’t see you for some time”.

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



Share on:   Facebook   Twitter   Reddit   Tumblr   Pinterest




You may also like

en Old Code, October 31, 2018
en Fast JSON Schema for Python, October 1, 2018
en Open Source Responsibilities, September 6, 2018
en Deployment of Python Apps, August 15, 2018
en Nginx X-Accel Explained, July 31, 2018


Popular from code

en Makefile with Python, November 6, 2017
en Deployment of Python Apps, August 15, 2018
cs Jasně, umím Git…, August 6, 2014
cs Checklist na zabezpečení webových aplikací, March 1, 2016
cs Pokročilé regulární výrazy, August 17, 2014