Technical debt will ruin you. If you allow, of course
Translated by localization company Alconost .
')
This happens more often than I would like to consider. Behind the glittering interfaces of many applications are Lavkraftovsky architectural horrors that challenge the sanity of anyone who has been able to support them or add new features. Ask the developers - each of them has a couple of scary stories about it.
If your application of these - works, but suboptimally, not elegantly, 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, rooms in it can be comfortable and well decorated, but all this beauty can stand on such a bad foundation that if you have a tougher guest who wants to run down the stairs, everything will collapse. The matter may not even be in the foundation, but in the soil that is unsuitable for construction, and then replacing the foundation will not help: you have to rebuild the house 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 in place for ages, while iOS and Android went ahead, leaving BlackBerry in the wake of? Their failures were not due to design choices or conscious leadership decisions. They happened because of the huge technical debt, to get rid of which the company took years.
As well as monetary, technical debt is quite normal until a) it becomes too large, and b) you know everything about it. Of course, it is often necessary to resort to compromises between, say, scalability and development speed. When the deadline approaches and / or funding ends, and the task seems huge, it happens that a quick hack is the right choice. It can be understood that all developers prefer to use familiar or interesting tools for learning, and not at all ideal for doing work.
But more often, the accumulation of technical debt for the sake of short-term gain is a terrible mistake. Like any debt, technical debt worsens over time. Worse, the majority of non-technical specialists — that is, too many managers, managers, and founders — usually underestimate its danger or do not understand what they create at all until they have been working for months only to eliminate technical debt; while their competitors happily continue to move forward. That is exactly what happened with RIM.
So how do startups avoid this unenviable fate?
Of course, it is crucial to hire the right people. It also helps pair programming using the “ master / verifier ” model, which I especially love. And it always seemed to me that technical assessments are a good idea: let a few 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 not. Then try to determine whether it is possible not to rebuild your metaphorical house, but only to replace its foundation (even though the previously worked things will break again during the reconstruction, which is always very annoying), or you will have to drop everything and start new construction. Each of these solutions may be the best and fastest.
But listen to your developers the most. If you hire the right people, they want clean, extensible, scalable code just like you. It was almost painful to see the Postography source code we got. Now I feel as if we had an operation that not only saved the life of a 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 to do.
About the translator
The article is translated in Alconost.
Alconost is engaged in the localization of applications, games and websites in 60 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.
We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.
Read more: https://alconost.com
Recently, the project I was working on finally started. Okay, restarted. It's about a small unpretentious application for iPhone Postography , which allows you to send paper postcards with pictures and text from your iPhone. Great and seemingly simple project, right? An application that was not supposed to take much time to create.
Unfortunately, we did not do it from scratch, but reworked it. And the company that first took up the development (let's not call it here), seriously worked on the server part, but epically failed the first version of the application itself. Oh yes: in the end, in a sense, it even worked, despite the 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 full rewriting.
')
This happens more often than I would like to consider. Behind the glittering interfaces of many applications are Lavkraftovsky architectural horrors that challenge the sanity of anyone who has been able to support them or add new features. Ask the developers - each of them has a couple of scary stories about it.
If your application of these - works, but suboptimally, not elegantly, 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, rooms in it can be comfortable and well decorated, but all this beauty can stand on such a bad foundation that if you have a tougher guest who wants to run down the stairs, everything will collapse. The matter may not even be in the foundation, but in the soil that is unsuitable for construction, and then replacing the foundation will not help: you have to rebuild the house 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 in place for ages, while iOS and Android went ahead, leaving BlackBerry in the wake of? Their failures were not due to design choices or conscious leadership decisions. They happened because of the huge technical debt, to get rid of which the company took years.
As well as monetary, technical debt is quite normal until a) it becomes too large, and b) you know everything about it. Of course, it is often necessary to resort to compromises between, say, scalability and development speed. When the deadline approaches and / or funding ends, and the task seems huge, it happens that a quick hack is the right choice. It can be understood that all developers prefer to use familiar or interesting tools for learning, and not at all ideal for doing work.
But more often, the accumulation of technical debt for the sake of short-term gain is a terrible mistake. Like any debt, technical debt worsens over time. Worse, the majority of non-technical specialists — that is, too many managers, managers, and founders — usually underestimate its danger or do not understand what they create at all until they have been working for months only to eliminate technical debt; while their competitors happily continue to move forward. That is exactly what happened with RIM.
So how do startups avoid this unenviable fate?
Of course, it is crucial to hire the right people. It also helps pair programming using the “ master / verifier ” model, which I especially love. And it always seemed to me that technical assessments are a good idea: let a few 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 not. Then try to determine whether it is possible not to rebuild your metaphorical house, but only to replace its foundation (even though the previously worked things will break again during the reconstruction, which is always very annoying), or you will have to drop everything and start new construction. Each of these solutions may be the best and fastest.
But listen to your developers the most. If you hire the right people, they want clean, extensible, scalable code just like you. It was almost painful to see the Postography source code we got. Now I feel as if we had an operation that not only saved the life of a 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 to do.
About the translator
The article is translated in Alconost.
Alconost is engaged in the localization of applications, games and websites in 60 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.
We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.
Read more: https://alconost.com
Source: https://habr.com/ru/post/174521/
All Articles