Is business and selling features more important than the quality of the codebase?

Question

Project management

It's about web development. All the companies I meet spend more time on management and sales, user growth than on the codebase. All the projects I met had a bad code base, I dealt with the CIS and foreign projects. Large business applications are mostly procedural in style with if-else constructs littered with countless task-referencing comments. From this follows a large number of negative consequences, which undermine this very business in proportion to the movement of the technical debt schedule towards stagnation.

Answer 1

Lol. Congratulations on your insight. A programmer (administrator, lawyer, whatever) is just a specially trained monkey, and management runs everything. So it was, so it is, and so it will be, and the top does not care at all that procedural constructions offend the tender feelings of some chelik who is here today and gone tomorrow.
PS Just in case, I will answer separately - the answer to the question from the title: "Yes".

Answer 2

There is such a thing as "technical debt". The bottom line is that if you do not cut it in a timely manner, large "interest" can run up on it. This can be expressed in the failure of deadlines, a large number of bugs, the fragility of the system and the complexity of understanding for the user, the cost of operation, burnout of employees, and so on. It is often necessary to "borrow", but it is just as important to "repay" it in time. If you have not come across this concept before, I recommend reading the primary sources.
Management and salespeople always have a bias towards features, since a feature is something that can be seen and felt. On the other hand, technical debt is impossible for an outside observer to estimate, so he will always doubt that technical debt can affect profits. Therefore, it often happens that technical debt kills a good project. But this happens slowly and imperceptibly, and the reasons are usually written off to another account.
It is rare to find a project with a competent approach to managing technical debt. But there is a way out, and it is that the most authoritative technical specialists on the project systematically conduct explanatory work with those who make decisions, and the concept of "technical debt" helps very well in this communication - especially after another fakap in production. Some managers sometimes after that learn to reckon with the opinion of techies. But they can also send the forest.