Technical debt will ruin you. If you allow, of course
Recently, the project I was working on finally started. Ok, restarted. We are talking about a small simple Postography iPhone application that allows you to send paper cards with pictures and text from your iPhone. An excellent and seemingly uncomplicated project, right? An application for the creation of which should not have taken much time.
Unfortunately wethey didn’t do it from scratch, but redid it. And the company that first took up the development (we will not call it here), seriously worked on the server side, but epically failed the first version of the application itself. Ah, yes: in the end, in a sense, it even worked, despite many errors and sudden failures. But at the same time, its source code was such a cesspool of global variables, poorly structured code, hacks, garbage commands and locks that it was almost impossible to add or edit it without a complete rewrite.
This happens much more often than I would like to consider. Behind the sparkling interfaces of many applications are hidden Lovecraftian architectural horrors that challenge the sanity of anyone who has had the opportunity to support them or add new features. Ask the developers - each of them will have a couple of scary stories about it.
If your application of these works, but is not optimal, not elegant, does not expand or scale well, it means that you already have a solid technical debt ; and whether you realize it or not, you already have big problems.
I like to use the housing metaphor: your house can look great, the rooms in it can be comfortable and well decorated, but all this beauty can stand on such a poor foundation that if you have a denser guest who wants to run down the stairs, everything will collapse. It may not even be the foundation, but the soil unsuitable for construction under it, and then replacing the foundation will not help: you will have to build the house again in some other place.
This happens even with advanced technology companies. Take at least RIM. Remember, they released a tablet without an email client? Remember how they quietly stagnated for ages, while iOS and Android went ahead, leaving the BlackBerry in the wake? Their failures were not driven by design choices or by conscious leadership decisions. They happened because of a huge technical debt, the company took years to get rid of.
Like money, technical debt is quite normal until a) it becomes too large, and b) you know everything about it. Of course, one often has to resort to compromises between, say, scalability and development speed. When the deadline approaches and / or the funding ends, and the task seems huge, it happens that a quick hack is the right choice. You can also understand that all developers prefer to use familiar or interesting tools for learning, but not ideal for the job.
But more often than not, accumulating technical debt for short-term gain is a terrible mistake. Like any debt, technical debt is compounded over time. Even worse, most non-technical specialists — that is, too many managers, supervisors, and founders — usually underestimate its danger or don’t realize that they are creating it until they have to work for months to eliminate their technical debt; and their competitors, meanwhile, happily continue to move forward. This is exactly what happened with RIM.
So how do startups escape this unenviable fate?
Of course, it’s crucial to hire the right people. Pair programming using the master / reviewer model also helps."Which I especially love. And it always seemed to me that technical evaluations were a good idea: let some experienced specialists spend a week auditing your code and architecture, once at the very beginning of development and once again somewhere in the middle of the process. The company I work for has done this once or twice, but, unfortunately, technical assessments have not yet become common practice for the industry.
What can be done if you have already accumulated serious technical debt? First of all, get your head out of the sand and admit that you have a big problem. Next - stop digging. Stop adding new features and bring everything to a semi-stable state to see what you have and what you don’t have. Then try to determine whether it is possible not to rebuild your metaphorical house, but only to replace its foundation (even though the previously working things will break again during the reconstruction, which is always very annoying), or you will have to give up everything and start a new construction. Each of these solutions may be the best and fastest.
But most of all, listen to your developers. If you hired the right people, then they want clean, extensible, scalable code just like you. It was almost painful to browse the Postography source code we got. Now I feel like we had an operation that not only saved the life of the victim of a terrible car accident, but also gave her the opportunity to become an Olympic athlete. It's never too late to save your application, but the sooner you start, the easier it is.
About the translator
Translation of the article was done in Alconost.
Alconost localizes applications, games and sitesinto 60 languages. Native translators, linguistic testing, cloud platform with API, continuous localization, project managers 24/7, any format of string resources.
We also make advertising and training videos - for sites that sell, image, advertising, training, teasers, expellers, trailers for Google Play and the App Store.
Read more: https://alconost.com