You work as a programmer and you write code almost every day. Tell me how often do you feel satisfaction from the work you do and pride in the results of your work? Have you ever produced working but poor-quality and “ugly” code just to meet deadlines? Are you motivated to write optimal code knowing that it will become irrelevant and useless in a couple of months?
Let’s try to find out how it happened that programming has turned from a beautiful art and creativity into a daily routine conveyor.
Sweatshop conveyor belt
If you work at a commercial company, you are probably familiar with the term “time to market” – the time interval between the emergence of a product idea or functionality and the release of the ready product on the market. Nowadays, everyone is trying to shorten this interval. In commercial development the acceleration of processes rules.
Releases follow one after another, all the participants of software development are always behind the schedule and work overtime. And all this is done with one purpose – to sell the ready product to the customer as soon as possible. There are no more frills in development and no more quality code – the conveyor must not stop.
The product is released on time, possibly even without critical errors: the goal is achieved. But everyone who participated in the development can see perfectly well what is going on behind a beautiful advertising facade. Technical debt is constantly piling up in the system, the amount of “hardcore” is increasing, and all the temporary solutions become permanent. Attempts to fix the situation in any way usually go nowhere: “It’s very good that you noticed this, but there’s no time to fix it now, but maybe we’ll fix it in the future.” Everything stays the same and, based on all this shaky design, the system continues to evolve and new functionality is implemented.
Plastic World
On the other hand, who needs durability and quality now? Most of the code you write will be used in the system for a few months at most and then will be replaced or reworked. What’s the point of writing this code perfectly then? Imagine that you’re plastering a room in a house every day, knowing full well that the house will be torn down in a day. Anyone would give up.
It seems that many companies are simply not profitable to produce a quality product that lasts. If you make a smartphone comfortable and reliable, who among the consumers will want to buy a new one in a year? This is how the phenomenon called “planned obsolescence” came about. We all live in a plastic world of short-lived things.
Recall, for example, how Microsoft accidentally released the fairly tolerable Windows XP. Users liked it so much that they were loath to upgrade to the next version. Then the story was kind of repeated with Windows 7. But Microsoft no longer made such “mistakes” – the transition to the next version of the system became voluntary and compulsory.
Apparently, for these reasons nowadays people think less and less about the beauty and optimality of the released systems. The principle of “Do you want to get by or do you want to get by?” prevails in commercial development.
The Art of Programming
So who is the modern developer: a craftsman with a satisfactory knowledge of the tool, or a master who has reached the pinnacle of his art? This question has been around for years. It seems that in today’s world of development creative craftsmen are not expected at all. I often encounter such an attitude of management: “According to my boss, programming is a craft. And it is useless to argue with him. He thinks that a programmer with a creative approach to business is bad for him and he should not be hired in any case.
Many of the artists are even forced to disguise themselves as artisans in order to survive: otherwise they will not be able to meet the prohibitive deadline.
Of course, in any business, you need not only high-caliber craftsmen. Everywhere there is work for the average worker who completed a six-month programming course on one of the training sites. But the problem is that this steadily reduces the quality of programs. Installing a new version of some mobile app turns into a game of “guess what else they’ve managed to break.” Unless there is a knowledgeable, educated engineer on the construction site, even the most diligent and disciplined workers can build a good, reliable house except by accident.
Donald Knuth called his book The Art of Programming. The first edition of the book was published back in 1968. Back then, programming was still an art. It is a pity that the profession of programming is gradually becoming more and more pragmatic and down-to-earth. But at least in our own projects we can always engage in free creativity and not play by corporate rules.