So what is the ultimate goal of programming?

I was inspired to write this post by the article “What is the ultimate goal of programming?” and its discussion in the comments. I upvoted the article as soon as I read the first sentence:

It’s about having code that is easy to change.

After all, this is obvious to anyone who has programmed long enough to be faced with the need to change their own code after some fairly long time (more than six months from the completion of the project). I’m not talking about other people’s code, because for the most part it is initially written by “crooked people” your-favorite-epithet“And you need to spend a lot of time at least to understand what it does, and in order to change something in it and not destroy everything else, you need to spend many times more time.

But an article with such an obvious (well, for me personally) conclusion has, as of today, a rating of “-5” (“8” is a plus, “13” is a minus). Below the cut are my thoughts on the possible reasons for this.

As a result of discussions in the comments with colleagues @hlogeon and @saboteur_kiev (thanks to them for their suggestions), the well-known “Maslow’s pyramid” finally appeared before my eyes:

At the base of the pyramid are the basic needs, and any “excesses” are located at the upper levels. The need for them begins to appear only after the basic ones have been satisfied.

If you imagine programming goals in the form of a similar pyramid, then I would arrange them in this order (from basic to “excesses”):

Write

The ultimate goal of programming is the program text itself. This is so obvious that it ceases to be perceived as the ultimate goal after the second or third independently written program.

Compile

The ultimate goal of programming is to create a compilable program. For programmers in interpreted languages, the goal can be considered to create a program such that each line of it does not cause errors associated with the interpretation of the code. By the way, modern IDEs are very helpful in creating “compiled” programs.

Run

The ultimate goal of programming is to create a working program. There are times when the code compiles successfully, but the program crashes immediately after launch. Or not immediately – it crashes under certain conditions. Division by zero, stack overflow, undefined, etc. – all these things make it impossible to use a program, even if it is written and compiled (or the IDE does not detect errors in it).

Business

The ultimate goal of programming is to create a program that solves some business problem. Indeed, from the point of view of a capitalist society, there is no point in paying money for useless programs, even if they compile successfully and work without errors.

Test

The ultimate goal of programming is to create a testable program. Not every project may need this level. But when a project needs testing, this leaves its mark on the coding style (TDD, dependency injection, etc.). As a rule, these are projects with a large code base and high turnover in the team.

Modify

The ultimate goal of programming is to create an easily modified program. These projects, as a rule, have a long lifespan (over months) and an iterative approach to development (you can immediately remove landing pages for rural stores from this list, but leave in it the engine for creating these same landing pages).

Total

Thus the pyramid”main goals” programming might look like this:

I am sure that it is possible to add more levels of “main goals”, but with my experience I can only see these. Someone else may find more goals that begin to manifest themselves after achieving those described here.

The level of a goal does not mean its “weight” – it is clear that if a program does not solve any business problem, then everyone except its creator has no idea how well it compiles or tests. The level only says that there is no point in achieving the current goal if the underlying ones have not been achieved. Those. There’s no point in implementing business logic in a program that doesn’t work – you need to make it work first. There is no point in making a program testable that does not solve a business problem, just as there is no point in worrying about the modifiability of code that is not covered by tests.

In my opinion, there are many ultimate goals in programming. They are like nesting dolls nested inside each other. What a particular programmer in a particular project takes as the final goal depends both on the experience of the programmer himself and on the project. Some projects really don’t make sense to rise above business goals.

Well, colleague @undeadlol1 was downvoted in vain, in my opinion.