Why we fail to keep good-quality software

When you become a programmer, you hear a lot that you need to deliver good-quality code. The code should be readable and easy to understand for other developers. It should also be maintainable. Oh, and you should write unit tests. But have you ever seen any project that has a readable code? Is it free of a technical debt? And is easy to maintain? I guess not too often, right?

Have you ever asked yourself why?

Let’s imagine Steve. He is the owner of a small startup and has an excellent (he thinks) idea for a product. He recently got funding for MVP. In 3 months he will need to show something to his investors in order to convince them to continue supporting his idea. He finds a software house that will make his idea a real product.

Now, let’s imagine Bob. He is new to this software house and was recently promoted to mid developer. In his previous jobs, he didn’t have any influence on architecture or technical stack decisions. Finally, he gets to the point when his voice matters. Bob and other developers are asking themselves how they want to help Steve materialize his idea.

He has in his mind everything he has ever heard about good-quality code. He thinks: This time I will make this neatly. This will be a project with thorough architecture, with continuous refactor and high coverage of a unit test. Something to be proud of.

The scope of MVP has been set. The development team has established the architecture and some technical stack. And after two weeks they start to code. The team doesn’t deliver software frequently and Steve is not pleased with the progress. He starts to push developers. Bob and his friends give up on a unit test. But Steve is still fearful. He pushes even more. The team gives up some patterns and then a code review. They stop to pair program and start to do overtime and whatever they need to catch up in time. But Steve keeps pushing.

As you can imagine, this continuous process will eventually lead us to the point where we don’t have any good quality standards. However, Bob and his team have met the deadline. Steve isn’t completely satisfied with the delivered product but at least he has something to show to his investors. Everybody is happy this is finally over.

And now there are two scenarios. In the first one, the product is a piece of crap and investors kill it. In the second one, the investors like it and want to continue funding it. Steve comes back and wants Bob to deliver the next milestone. You can imagine how happy Bob is to work on a legacy code. He swears that this time he will refactor piece by piece. And guess what? The situation repeats itself. This time investors release the product. However, users are disappointed and complain about a number of bugs.

We can ask how this happened, but we’ve all been there. Someone didn’t stop it. Who should have done it?

It could have been anybody who’s aware of a problem, perhaps someone from Development team or even Bob. So why no one tried to fix it? Why don’t you do it when you are a part of that development team?

Most of us, developers, are introverts. We don’t talk too much. Every sentence is carefully considered. It is extremely hard to admit that nothing goes according to the plan. Often you feel pressure, not only from your client but also from people you work with. In this case, you haven’t got any support.

I have no ready solutions or answers. The problem remains and it’s up to us to tackle it or we will keep running around in circles. Why wouldn’t you stop it?