The post has been translated automatically. Original language: Russian Russian
Hi! My name is Dmitry Pankin, I am the founder of the companyResolventa. We create complex IT products for clients: marketplace sites, B2B portals, personal accounts, applications, custom CRM and ERP systems.
When a company wants to update its IT system, it gets a lot of bad advice from programmers: delete, throw out, re-write in a different language. This approach is 99% beneficial only to the developers themselves, businesses go bankrupt because of it. And now for more details.
Almost no IT system can run forever on only one technical support - neither an online store, nor a CRM system, nor a personal account. That's why the service will need a complete upgrade or replacement sooner or later.
The business has grown or changed. Sometimes, at the start, it is difficult for an entrepreneur to assume that a small "garage" project will grow into a huge company with several departments. Therefore, technical specifications for an IT system are often written as if it will always be small. The developers do not take into account the subsequent scaling:
- They don't use automated tests.;
- They are not building a sustainable architecture;
- they don't conduct a cross-code review;
- they don't keep the code clean.
At the start, this approach can even be beneficial: you can quickly create a minimally viable version of the service and enter the market with it in order to test it in real conditions. But if you skip the moment when the scale increases, endless bugs will start popping up, the service will process requests slowly and stop coping with the amount of data.
Technology is outdated. Since the writing of the IT system, several new versions of the programming language may be released. As a result, your version will become outdated and will be without official support. This means that the vulnerabilities in it will not be eliminated and new features will not be added. This is critical for the development and scaling of any business, so you need to update the service and switch to a new version of the language.
We use PHP at Resolventa, so we will talk about it in the article. For example, we strongly recommend updating the service if the PHP version is lower than 7.0. The same applies to outdated frameworks, for example: Yii, CodeIgniter, CakePHP, Symfony 2.0.
To find out if the language version you are using is supported, look at the list of releases on the official website. In the case of PHP, you need to go to php.net , and for the Symfony framework — on symfony.com .
The screenshot shows an example of how we updated the PHP version when upgrading one of the projects. As a result, the site started loading 2.5 times faster.
The project was written by an insufficiently qualified team. It happens that the service is initially written carelessly and hastily. As a result, the code is dirty, programmers don't do refactoring and review — there's no time. This may be the fault not only of the developers, but also of the managers: they may set too short deadlines and constantly adjust the team, provoking new mistakes.
Sometimes, at the start, a business simply does not have the money for an experienced development team, and the IT system is ordered from someone who offers a more affordable price. While the service is small, the low quality of the code is not noticeable, but with the development of the business comes the collapse. This does not mean that the approach was wrong. It's just that the team didn't react in time and didn't update the system before problems arose.
So, if any of the above is about your service, then it needs to be updated.
Imagine: the logistics company Transportation noticed that the internal system for employees began to slow down due to the large amount of data, and contacted the IT agency with this problem. In addition, she needs to add a new feature to her personal account and make an adaptive version so that the service is convenient to use from a smartphone, but current technologies do not allow this.
There is a 90% chance that the following dialogue will take place at the agency:
— What stack is your service currently written on?
— The developers say that in PHP…
— Hence the problems. Let's write everything from scratch on a modern Node.js. This will allow you to use a single JavaScript language to write code both on the client side and on the server. As a result, it will be much faster, and it will be easier for developers on the frontend and backend to collaborate with each other.
— Is there really no way to save what you have?
— It will be unprofitable for you. Trust our experience.
— Okay…
Introduced? This is how negotiations on how best to recreate your service usually end. Writing from scratch is beneficial for programmers, but more often than not it's a critically bad idea for a business.
I'll explain why programmers give such advice in general.
Each company has its own technology stack: one agency specializes in PHP, another in Python, and the third in Node.js . If the customer has a different stack, the developers simply cannot immerse themselves in his project, because the team does not have specialists who work in this programming language.
A screenshot from the Resolventa website, which shows the stack of our specialists. You can find a similar list on the website of any IT company. This will help you find out if they are working with the same technologies as your developers.
The developers are not competent enough. Understanding someone else's code is much more difficult than writing a project over again. We need experience in solving similar problems and a personal approach, not just the practice of solving typical tasks. This requires qualified staff. If you are offered to rewrite the project from scratch, it is possible that the company simply does not have senior programmers on staff to modernize it.
It is beneficial for the agency to take your order, but it is too stressful to modernize the service step by step. As a result, programmers naturally begin to push through their decision to completely rewrite the project. This is how they get paid and don't complicate their lives by working with someone else's stack and legacy. This is usually argued by the fact that the agency's technological stack and approach to solving problems are the most modern, while the customer's are dense and outdated — that's all that slows down.
We believe that the task of a conscientious developer is to preserve the service if possible. Let's find out why in most cases it is more profitable to modernize an old IT system and when you still have to rewrite everything from scratch.
It usually takes about the same amount of time to develop a service from scratch as it took to create it the first time. For example, if an online store was built in a year, then its new version will not appear earlier.
All this time, the business must live with the old IT system, which, although it does not fully perform its functions, is still necessary. There are two options for what to do with it: leave everything as it is — at tech support — or put crutches and fix the service in parallel with the creation of a new one. Each solution has its own significant disadvantage.:
If you do not touch the old service, you lose the possible profit. For example, in our practice, there was a customer with a B2B portal, he sold subscriptions to his service. It was assumed that while we were making a new version of the portal, customers would use the old one and wait for the release. But some were not satisfied with bugs and non-adaptive design, so they unsubscribed from the service. As a result, the customer missed out on a portion of the profit.
If you fix an old service along with creating a new one, you double the costs. You will have to maintain two development teams: pay twice as much and spend management resources to control both. This is a big burden on the business. And there is also a risk of conflict: the developers of the current version feel that the outdated service will be buried with them, so they can sabotage cooperation with the new team.
In my experience, there are almost no situations where the system cannot be restored: you can always go through the old code and upgrade the platform. But there are cases when it is impractical. Here are two circumstances in which it is better to rewrite the system from scratch.:
The technologies used are hopelessly outdated. The project will have to be recreated if the technology is not just obsolete, but dead. This happens if the version of the language in which your service is written has not been supported for a long time. For example, when the product is written in PHP 5.0, which was deprecated back in 2008.
If your service's code looks like this, you shouldn't upgrade it. It's better to bury it and write from scratch
CMS is used. Designers such as WordPress and Bitrix are good for small or typical online stores and other simple IT systems. If a business is growing, over time it will need new customized solutions that cannot be implemented on a CMS.
Alas, upgrading a service originally written on a CMS is incredibly expensive and difficult. To do this, you need to know the device of a particular CMS from the inside and not just configure it, but be able to rewrite important parts of the source code. There are very few such specialists on the market.
In all other cases, when the service is written in a language version that is still supported and the CMS is not used, I recommend upgrading. For a business, rebuilding an old service is almost always better than building a new one.
If management chooses a step-by-step modernization strategy, it will be possible to expand and increase business efficiency in parallel with the reconstruction of the IT system. You won't have to pause processes for a couple of years while writing a new software platform for the company.
It may seem to business management that it is more expensive to modernize a service than to develop it anew. This is not always the case. The final price is influenced by several factors. Let's first consider those that increase the price of a phased recovery.:
- Payment of qualified personnel. Upgrading is more difficult than creating a project, so higher-level specialists are required here. Their cost is higher, so salaries can increase the budget.
But, on the other hand, a low—budget team is unlikely to be able to write even a new project well - there is a risk that in a couple of years it will have to be rewritten again.
- Time costs. Upgrading the system step by step is laborious, and it can take a considerable amount of time. Businesses will carry this financial burden for longer, withdrawing money from other budget items.
But there are points that reduce the cost of modernization work.:
- Using ready-made parts of the code. When restoring, you do not need to rewrite the sections of the old system that are functioning well. This reduces development costs. This is not possible when creating a project again.: one hundred percent of the code must be written from scratch.
- The work of just one team. There is no need to keep individual developers to support the old service and create a new one, you do not inflate the staff of programmers.
To determine exactly which option is optimal for the business, I recommend conducting a qualified external IT audit. Experts will look at the condition of your service, calculate the cost of writing from scratch and upgrading, and help you make a conclusion.
- Update the service if the business has grown or changed a lot, the technology is outdated, or, for example, 10 years have passed since the last upgrade.
- Upgrading the project step by step is the most profitable solution for the company in most cases. This way you won't have to double your expenses, lose profits and customers, or freeze business growth.
- Rewrite the service from scratch if it is made in PHP 5.0 and earlier versions or written using a CMS. In these cases, upgrading the service will be more difficult than writing it over, which means it will take many hours for programmers and will be too expensive.
At Resolventa, we have been helping startups and large businesses around the world restart services and create new ones since 2012. We also conduct a technical audit: if you have not yet decided whether to modernize the system or rewrite what exactly to change and how to optimize it.
Write in person — we will analyze the problem and set a date for consultation on your IT project.
Привет! Меня зовут Дмитрий Панькин, я основатель компании Resolventa. Мы создаем сложные ИТ-продукты для клиентов: сайты маркетплейсов, B2B-порталы, личные кабинеты, приложения, кастомные CRM- и ERP-системы.
Когда компания хочет обновить свою ИТ-систему, ее ждет куча вредных советов от программистов: удалить, выкинуть, написать заново на другом языке. Этот подход в 99% выгоден только самим разработчикам, бизнесы из-за него разоряются. А теперь подробнее.
Почти ни одна ИТ-система не может работать вечно только на одной техподдержке — ни интернет-магазин, ни CRM-система, ни личный кабинет. Вот почему сервису рано или поздно потребуется полное обновление или замена.
Бизнес вырос или изменился. Иногда на старте предпринимателю сложно предположить, что небольшой «гаражный» проект разрастется до огромной компании с несколькими департаментами. Поэтому техзадание для ИТ-системы часто пишут так, будто она всегда будет маленькой. Разработчики не учитывают последующее масштабирование:
- не используют автоматизированные тесты;
- не строят устойчивую архитектуру;
- не проводят перекрестное код-ревью;
- не следят за чистотой кода.
На старте такой подход бывает даже выгодным: можно быстро создать минимально жизнеспособную версию сервиса и выйти с ним на рынок, чтобы протестировать в реальных условиях. Но если пропустить момент, когда масштаб увеличится, начнут вылезать бесконечные баги, сервис станет медленно обрабатывать запросы и перестанет справляться с объемом данных.
Технологии устарели. С момента написания ИТ-системы может выйти несколько новых версий языка программирования — в итоге ваша версия устареет и окажется без официальной поддержки. А значит, уязвимости в ней уже не устранят и новых функций не добавят. Это критично для развития и масштабирования любого бизнеса, поэтому нужно обновлять сервис и переходить на новую версию языка.
Мы в Resolventa используем PHP, поэтому в статье будем говорить именно о нем. Например, мы настоятельно рекомендуем обновить сервис, если версия PHP ниже, чем 7.0. То же касается устаревших фреймворков, например: Yii, CodeIgniter, CakePHP, Symfony 2.0.
Чтобы понять, поддерживается ли версия языка, которую вы используете, загляните в список релизов на официальном сайте. В случае с PHP нужно зайти на php.net, а для фреймворка Symfony — на symfony.com.
На скриншоте пример того, как мы обновили версию PHP при модернизации одного из проектов. В результате сайт стал загружаться в 2,5 раза быстрее
Проект писала недостаточно квалифицированная команда. Бывает, что сервис изначально пишут небрежно и наспех. В результате код грязный, программисты не делают рефакторинг и ревью — некогда. В этом может быть вина не только разработчиков, но и менеджеров: они могут ставить слишком сжатые сроки и постоянно подгонять команду, провоцируя на новые ошибки.
Иногда у бизнеса на старте просто нет денег на опытную команду разработчиков — и ИТ-систему заказывают у того, кто предложит более доступную цену. Пока сервис небольшой, низкое качество кода не бросается в глаза, но с развитием бизнеса наступает коллапс. Это не значит, что подход был неверный. Просто команда не среагировала вовремя и не обновила систему до того, как возникли проблемы.
Итак, если что-то из перечисленного выше про ваш сервис, значит, его нужно обновить.
Представьте: логистическая компания «Перевозки» заметила, что внутренняя система для сотрудников стала тормозить из-за большого объема данных, и обратилась с этой проблемой в ИТ-агентство. Кроме того, ей надо добавить новую функцию в личном кабинете и сделать адаптивную версию, чтобы сервисом было удобно пользоваться со смартфона, но текущие технологии не позволяют это сделать.
С вероятностью 90% в агентстве состоится следующий диалог:
— На каком стеке сейчас написан ваш сервис?
— Разработчики говорят, что на PHP…
— Отсюда и проблемы. Давайте напишем всё с нуля на современном Node.js. Это позволит использовать единый язык JavaScript, чтобы писать код как на стороне клиента, так и на сервере. В итоге получится намного быстрее, а разработчикам на фронтенде и бэкенде будет проще сотрудничать друг с другом.
— А точно нет никакого способа сохранить то, что есть?
— Это будет вам самим невыгодно. Поверьте нашему опыту.
— Окей…
Представили? Именно так обычно и заканчиваются переговоры о том, как лучше пересоздать свой сервис. Написание с нуля выгодно для программистов, но чаще всего критично плохая идея для бизнеса.
Объясню, почему вообще программисты дают такие советы.
У каждой компании свой технологический стек: одно агентство специализируется на PHP, другое — на Python, третье — на Node.js. Если у заказчика другой стек, разработчики просто не могут погрузиться в его проект, потому что у команды нет специалистов, которые работают на этом языке программирования.
Скриншот с сайта компании Resolventa, на котором показан стек наших специалистов. Вы можете найти подобный список на сайте любой ИТ-компании. Это поможет узнать, работают ли они с теми же технологиями, что и ваши разработчики
Разработчики недостаточно компетентны. Разобраться в чужом коде намного сложнее, чем написать проект заново. Нужен опыт в решении аналогичных проблем и персональный подход, а не только практика решения типовых задач. Для этого требуются квалифицированные сотрудники. Если вам предлагают переписать проект с нуля, — возможно, в штате компании просто нет сеньор-программистов, чтобы провести модернизацию.
Агентству выгодно взять ваш заказ, а вот поэтапно модернизировать сервис слишком напряжно. В итоге программисты закономерно начинают продавливать свое решение полностью переписать проект. Так они получают деньги и не усложняют себе жизнь работой с чужим стеком и легаси. Аргументируют это обычно тем, что технологический стек и подход к решению задач у агентства самые современные, а у заказчика дремучие и устаревшие, — вот все и тормозит.
Мы считаем, что задача добросовестного разработчика — сохранить сервис, если это возможно. Давайте разберемся, почему в большинстве случаев выгоднее модернизировать старую ИТ-систему и когда все-таки придется переписывать всё с нуля.
На разработку сервиса с нуля обычно уходит примерно столько же времени, сколько было потрачено на его создание в первый раз. Например, если интернет-магазин сделали за год, то и его новая версия появится не раньше.
Все это время бизнес должен жить со старой ИТ-системой, которая хоть и не выполняет своих функций полностью, но все-таки необходима. Есть два варианта, что с ней делать: оставить всё как есть — на техподдержке — или ставить костыли и чинить сервис параллельно с созданием нового. У каждого решения есть свой существенный минус:
❌ Если вы не трогаете старый сервис, то теряете возможную прибыль. Например, в нашей практике был заказчик с B2B-порталом, он продавал подписки на свой сервис. Предполагалось, что, пока мы делаем новую версию портала, клиенты будут пользоваться старой и ждать релиза. Но некоторых не устраивали баги и неадаптивный дизайн, поэтому они отписывались от сервиса. В итоге заказчик упускал часть прибыли.
❌ Если вы чините старый сервис вместе с созданием нового, вы удваиваете расходы. Вам придется содержать две команды разработчиков: платить вдвое больше и тратить управленческий ресурс, чтобы контролировать обе. Это большая нагрузка на бизнес. А еще есть риск конфликта: разработчики текущей версии чувствуют, что устаревший сервис похоронят вместе с ними, поэтому могут саботировать сотрудничество с новой командой.
По моему опыту, практически не бывает ситуаций, когда систему невозможно восстановить: перебрать старый код и модернизировать платформу можно всегда. Но есть случаи, когда это нецелесообразно. Вот два обстоятельства, при которых, систему лучше все же переписывать с нуля:
Используемые технологии безнадежно устарели. Проект придется создавать заново, если технологии не просто морально устарели, а умерли. Так бывает, если версия языка, на котором написан ваш сервис, уже давно не поддерживается. Например, когда продукт написан на PHP 5.0, который устарел еще в 2008 году.
↑ Если код вашего сервиса выглядит так — модернизировать его не стоит. Лучше похоронить и писать с нуля
Использованы CMS. Такие конструкторы, как WordPress и Bitrix, хороши для небольших или типовых интернет-магазинов и других несложных ИТ-систем. Если бизнес растет, со временем ему потребуются новые индивидуальные решения, которые невозможно реализовать на CMS.
Увы, модернизировать сервис, изначально написанный на CMS, невероятно дорого и сложно. Для этого нужно знать устройство конкретной CMS изнутри и не просто конфигурировать ее, а уметь переписывать важные части исходного кода. На рынке таких специалистов очень мало.
Во всех остальных случаях, когда сервис написан на версии языка, которая еще поддерживается, и не используются CMS, я рекомендую модернизацию. Для бизнеса перестраивать старый сервис почти всегда лучше, чем делать новый.
Если руководство выбирает тактику поэтапной модернизации, можно будет расширять и наращивать эффективность бизнеса параллельно с воссозданием ИТ-системы. Не придется ставить процессы на паузу на пару лет, пока пишется новая программная платформа для компании.
Руководству бизнеса может показаться, что модернизировать сервис дороже, чем разработать заново. Это не всегда так. На окончательную цену влияют несколько факторов. Рассмотрим сначала те, что повышают цену поэтапного восстановления:
- Оплата квалифицированных кадров. Модернизация сложнее, чем создание проекта, поэтому здесь требуются специалисты более высокого уровня. Их стоимость выше, поэтому зарплаты могут увеличить бюджет.
Но, с другой стороны, низкобюджетная команда вряд ли сможет хорошо написать даже новый проект — есть риск, что через пару лет его придется переписывать вновь.
- Временные издержки. Поэтапно модернизировать систему трудоемко, это может занять значительное время. Бизнес будет нести эту финансовую нагрузку дольше, изымая деньги из других статей бюджета.
Но есть моменты, которые снижают цену работ по модернизации:
- Использование готовых частей кода. При восстановлении не нужно переписывать участки старой системы, которые хорошо функционируют. Это позволяет сократить затраты на разработку. При создании проекта заново такое невозможно: сто процентов кода надо писать с нуля.
- Работа всего одной команды. Нет необходимости держать отдельных разработчиков для поддержки старого сервиса и создания нового, вы не раздуваете штат программистов.
Чтобы точно определиться, какой вариант оптимален для бизнеса, я рекомендую провести квалифицированный внешний ИТ-аудит. Специалисты посмотрят, в каком состоянии находится ваш сервис, подсчитают затраты на написание с нуля и на модернизацию и помогут сделать вывод.
- Обновляйте сервис, если бизнес сильно вырос или изменился, технологии морально устарели или, например, прошло 10 лет с последней модернизации.
- Поэтапно модернизировать проект — самое выгодное решение для компании в большинстве случаев. Так вам не придется удваивать расходы, терять прибыль и клиентов, а также замораживать рост бизнеса.
- Переписывайте сервис с нуля, если он сделан на PHP 5.0 и более ранних версиях или написан с помощью CMS. В этих случаях модернизировать сервис будет сложнее, чем писать заново, — а значит, это займет много часов у программистов и обойдется чересчур дорого.
Мы в Resolventa помогаем стартапам и крупному бизнесу по всему миру перезапускать сервисы и создавать новые с 2012 года. Также проводим технический аудит: понадобится, если еще не решили, модернизировать систему или переписывать, что конкретно в ней изменить и как оптимизировать.
Пишите в личку — разберем проблему и назначим дату консультации по вашему ИТ-проекту.
Share
