I have taken you on a brief tour around a number of shortcomings when programming, and around why people, especially scientists and engineers, do not pay enough attention to them. Now the question that follows is: how important are these things? Are they just academic? Can I continue programming like this, even if it is a little suboptimal?
Here is one answer:
I know of one company that, in the late 80s, wrote a killer app. It was very popular, and lots of professionals bought and used it. But then the release cycles began to stretch. Bugs were not repaired from one release to the next. Load times grew and crashes increased. I remember the day I shut the product down in frustration and never used it again. The company went out of business a short time after that.
Two decades later I met one of the early employees of that company and asked him what had happened. The answer confirmed my fears. They had rushed the product to market and had made a huge mess in the code. As they added more and more features, the code got worse and worse until they simply could not manage it any longer. It was the bad code that brought the company down.
—Robert C. Martin, “Clean Code: A Handbook of Agile Software Craftsmanship”, 2009, p. 3
Incidentally, if you are interested in learning more about how to program better, that book is the bible.