Ads
Comments 13
+7
Парное программирование и модели «главный / проверяющий» самостоятельно не помогут избежать технического долга.
Очень редко технический долг вина непосредственных разработчиков, обычно ответственны за это руководители разных уровней, далекие от технической реализации.
+5
Технологический долг, как правило, есть всегда, вопрос только в его размере. Адекватные разработчики просто тихо рефакторят проблемные места и кажется что все под контролем.

Проблемы возникают когда:
— система растет слишком быстро долг не успевают отдавать
— меняются требования и то что было вчера нормально становится никуда не годно
— проблема настолько глобальна, что затрагивает все и вся — тогда решение по ней принимает, а точнее не принимает менеджмент
+1
Именно.

Системная проблема возникает, когда менеджмент оторван от технологии и эксплуатации слишком сильно. Тогда менеджмент не видит эксплуатационных проблем или не адекватно оценивает их как «быстренько исправьте и побежали дальше». Если одновременно менеджмент должен гнать сроки, то отсупать разработка может только за счет качества — потому что его не видно. :) Тогда возникает кризис — разработка считает, что все плохо из-за менеджмента, а менеджмент думает, что разработка вечно ноет, а надо бежать.
0
Очень точно сказано.

Видимо, большинство разработчиков с хабра работают в ИТ-компаниях. И там о таких разрывах, как правило, речи не идет. Поэтому им так легко строить зависимости роста технологического долга от степени адекватности разработчика. Понятно, что в очень простом случае такая зависимость есть и, возможно, она даже прямая. Но в реальном мире все как всегда сложнее.

Вот пример из жизни: Продукт запущен в срок, но в тот момент, когда менеджмент объявляет, что собирается запустить продукт именно в этот срок, разработчики с опытом хватаются за головы и, в кои-то веки, становятся инициаторами многочисленный собраний по этому поводу. В результате всех споров и недопониманий часть из них просто уходит.
Потом несколько месяцев после запуска царит полный [цензура] и разработчики «без перерыва на сон» вносят тысячи правок на живую, чтобы «заработало хоть как-то». А потом менеджмент бьет себя в грудь и говорит «Ребята, мы сделали!», а ребята находятся в «активном поиске» новой работы, потому что никто не хочет поддерживать «это», потому что понимают, что развивать «это» нереально. Нужно практически в буквальном смысле делать все заново. А на это, конечно, никто ни времени, ни ресурсов не даст. И менеджмент искренне недоумевает, почему разработчики недовольны и уходят. Ведь «Все работает! Чуть-чуть тут допилить, чуть-чуть там, а так все работает!», а на их место приходят новые, и первое время с легкостью выносят приговоры о компетентности предыдущих, потому что еще не понимаю куда попали.

А самое смешное в том, что этот продукт разрабатывался на смену старому «с косой-кривой» архитектурой, который невозможно было ни поддерживать ни развивать под новые задачи. И разработчики сами продвигали идею его создания, бились лбами о стены, в попытках доказать его необходимость и рисовали прекрасные картины, какими «фишками» можно будет этот продукт попутно наделить.

В результате пришел менеджмент, поставил эти фишки во главу угла, поставил нереальные сроки и начал под них все гнать. И что на выходе? Точно такое же говно, как и было. В чем-то превосходящее, в чем-то уступающее. Но в целом, такое же говно, вонючее и жиденькое. И никому не хочется брать его в руки и что-то из него лепить. Не более чем через полгода в отделе разработки не останется ни одного человека, который был бы свидетелем всех этих событий. И все пойдет по кругу.
+2
Черт, хотел эту статью перевести.

Вы меня опередили :)
+3
Мне кажется, ответственность за технологический долг несут две стороны:
1. Технари, которые реализуют неоптимальные решения
2. Менеджеры, которые не дают времени/ресурсов сначала на наём хороших сотрудников, потом на более тщательную реализацию, а затем не признают и не принимают вовремя необходимость доработок.

Поэтому, парным программированием и разработчиками этот долг не закрыть.
+2
Оптимальной работа будет тогда, когда руководитель ПО и менеджмент знает когда можно допустить технический долг и когда его нужно отдать. Программисты же часто поступают непрагматично с точки зрения бизнеса, например, пишут уж слишком чистый код.
0
По-моему, пример RIM в качестве иллюстрации опасности технического долга не годится и только вводит в заблуждение. Особенно в сочетании с советами насчет «парного программирования», т.к. провал RIM случился вследствие стратегических ошибок руководства компании.

Когда вышел первый iPhone, стало очевидно, что это гаджет следующего поколения с операционной системой другого типа и революционным интерфейсом. Но руководство RIM не ожидало быстрой потери рыночной доли и слишком долго продолжало сидеть на старой базе. В отличие от супергигантов, вроде Microsoft, Rim — относительно небольшая монопрофильная компания, у которой почти нет шансов догнать лидеров, засидевшись на старте. Из-за схожей причины неуспевания HP провалила запуск своих гаджетов на довольно хорошей WebOS.
0
Нанять правильных людей, тоже не достаточно для решения проблемы, ибо некоторые, даже очень зеленые, программисты считают что все делают «правильно».
0
И еще хуже, что они считают «неправильным» сделанное другими. «Все переписать!» — первый признак юного разработчика
-1
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
(с) bash.im/quote/420672
0
Кто-то злой поставил минус, а между прочим картина весьма реалистичная. Едва ли не большинство доминирующих продуктов сделаны криво и косо, все ругаются, но терпят. А тщательно продуманные и вылизанные архитектуры умирают из-за
— «пока добежим, все вкусное съездят» — продукт готов, а рынок занят.
— инвестор не вытерпел, деньги кончились. не у каждого есть терпеливый и верный инвестор.
— заплутали в идеалах. сделали все правильно, не учли нюанс, переделали еще раз правильно, еще раз не учли, еще раз переделали. запутались, умерли.
— изменились требования. «пока расчет производился, объект расчета в норке скрылся»
0
Технический долг совершенно нормален для любого живого проекта. «Девелопмент в рассрочку» — мы это называли так. Ценность получим сейчас, а проблемы отложим на потом.

Как любой долг, оно требует уплаты процентов. И если платить рассрочку не напряжно или проценты окупаются ранее полученной ценностью — то все нормально. А вот когда вся зарплата уходит на гашение кредитов — тут полный швах. А еще хуже — если на уплату одних процентов, даже без основного долга (как в историях про «русский стандарт») — это швах в квадрате. Вопрос гигиены, не более того. :)

Сам долг лучше бы мерить в количестве постоянных (recurrent) проблем, а не субъективном качестве кода. Я несколько раз наблюдал (и организовывал) смену команды разработчиков на проекте — и для всех живых проектов, абсолютно ВСЕГДА новые разработчики характеризовали старый код как «клоаку». Даже если команду сменить повторно — третья команда охарактеризует как «клоаку» творчество второй. :) Был даже пример обратной передачи — угадайте, что говорит первая команда про «что вы тут без нас наворотили?» :)
Only those users with full accounts are able to leave comments.  , please.