Consequences of neglected quality

“And in those days people will seek death and will not find it. They will long to die, but death will flee from them.”  Revelation 9:6

Hello everyone! I'm pleased, that you are reading these lines. I'm sorry for the excessively pompous epigraph, but I want to talk to you about the topic, which can't let me go.

Very often I hear people saying: `We shouldn't care about good code and system architecture, because we don't know whether the product will be a popular or not...`

Or something like this: `We will care about code and architecture in the next iteration, because the Sacred Agile allows us this trick...`

Yes. I want to talk to you about the “Technical debt”. And moreover, it would be great to hear your opinion about my thoughts and assumptions.

Let's assume that somebody created a product. He or she has done it with both or one of two assumptions: `agile let me not to think about architecture and code` (I still don't understated where people finds out something like that in agile), and `i think about it when the product shoots up` (But they don't usually fulfill the promise, because there is always something, that is more important).

Let it be a hot piece of software that provides an incredible valuable Internet service or this is a must-have mobile application on the Apple store. And the product has caught audience. I mean huge enough audience – million of average users. But this product has a lot of annoying bugs or limitations. Because, as we can notice, it is likely to be the product based on a spaghetti code, that is fragile and unpredictable in changes. Generally speaking, it brings all plagues that fast- and careless-written code can bring, especially if our hero has been developing it such a way for a long time.

Imagine the comments of user around. And imagine the future of this product. Can you? Let me help.

The case

The happy owner of this thing of course has a baggage. He or she has a team. Because such thing had to be created and promoted to get the million of average users. Somebody should support all of them (especially, because there are a lot of annoying bugs) etc. The product have a lot of features, because it has been developing for a long time.

Potential competitors of our start team can notice the huge market and a lot of problem our hero has. Whereas they have free hands. And they can take into account the problems and use them to eat a good piece of the market or kick the bad-quality rival off the market at all.

It seems to me that I hear: `Ok, Igor! But he or she is the leader (or something like that), he or she has prominence, and it is very hard to overwhelm it.` But at this point stagnation begins. Business is stopping to grow. Because competitors are eating the pie that is always not big enough to feed everyone. And our hero can't just add new features to make his bad-quality monster more likable. Because, when customers have a choice, the feature, they wants, is friendliness. I use such an uncertain term because the specifics depend on the case. But usually it is something like a button “Make me happy”, that works stable and fast, on the glossy screen of your iPhone.

And the problem is that our star team should begin development from scratch if they want to achieve such result.

Ok, let's talk about options of our hero.

Options

Option 1

He or she can completely refactor this software. On this point there are two branches. You have good coverage by automated tests or you don’t. If you don’t – you need the same (or even bigger) volume of efforts as you've spent to create this product.

If you have – you can save about a half of this amount of resources. (But I don't believe that our hero that doesn't bother about future has automated tests, even if he or she is so agile, as he or she think about).

Option 2 

He or she can create the version 2. If we look at software markets – a lot of people use this technique to balance their quality attributes with market needs. But it still requires the same or huger amount of resources that has been spent to build the first version. Nevertheless, sometimes it is even a standard part of a product life-cycle.

And there is one little thing, that the most people won't notice. If you go this two ways you can get a race. You can get a race with yourself. Because, if you are trying to compete on features, you have a chance to get into situation, when you have to write all features of the first version and add all features you'll have developed for the first version during development of the second version. It isn't a very pleasant situation.

In my experience, the refactoring of a 30% (one layer) of a complicated Magento module turned into 3 months of race instead of two weeks of work.

I don't want to tell, that it will certainly happen, because you can be wise enough or strong-willed to let 80% of feature, that are used by 20% of customers, go. Or something like that.

Option 3

Survive. Our hero can try to capitalize on his or her market share. He or she can live with this code. But you have to remember: good specialists don't like to be blamed for bad quality (especially by strangers) and don't like to deal with bad quality. So you'll get a spiral-down organizational culture (and may be quality too). Because it is hard to replace qualified in your product people with specialists that have the same abilities in a short term. Also I can add following. It is very difficult to force people write a better code than they see around them. And more over, it is hard to force people to write a good code at all. Somebody can or can't create a good code – and it doesn't absolutely matter, whether he or she understands why code should be qualitative. The main reason is: a huge part of people isn't able to notice cause and effect relationships between events that are distant in time. And more over, a lot of people (I can say with 100% sure only about Belarus) don't ready to protect interests of other people and especially their employer.

Options 4 and 5

Sell business, reinvest money and DON'T repeat such stupid mistakes. Or buy a competitor with good quality and migrate your clients to his or her platform.

Conclusion

Obviously, that late competitors have an advantage over the pioneers of a market if these pioneers put quality and quality attributes of their products on the third place and aren't wise enough to think further their nose. People like quick, simple, stable soft with good extensibility, interoperability and maintainability. Because such soft takes the shape of their mind and don't force them to change it themselves.

Afterword

In the beginning the price of suitable architecture is a couple of weeks for one or two experienced developers or architects working with an experienced in quality attributes analyst (may be a month - in case they overplay with some nuances, or they don't have enough experience in technologies they are going to use). At the end of such process you get an environment that is ready to develop a project with proper quality attributes.