It can be difficult for non-programmers to grasp the importance of writing good code. This story illustrates it:
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
How are you going to choose which IT consultant to trust? One might be fast, the other one may be slow. Is the fast one better? Or is he giving you messy code that will grind to a halt after two years? Is the slow one better? Or is he giving you even messier code and he’s incompetent even at that?
Many new businesses don’t pay much attention to this. They think “I need to get going fast, and I’ll worry about this later”. Somehow people think that “later” they will have more time available, when their experience should tell them the opposite. A successful business might have more money “later”, but if you’ve built a sucky software system bit by bit, the money and time and disruption and the total investment required to fix it “later” may be staggering. Companies have gone out of business because of this.