Comments 13
Парное программирование и модели «главный / проверяющий» самостоятельно не помогут избежать технического долга.
Очень редко технический долг вина непосредственных разработчиков, обычно ответственны за это руководители разных уровней, далекие от технической реализации.
Очень редко технический долг вина непосредственных разработчиков, обычно ответственны за это руководители разных уровней, далекие от технической реализации.
Технологический долг, как правило, есть всегда, вопрос только в его размере. Адекватные разработчики просто тихо рефакторят проблемные места и кажется что все под контролем.
Проблемы возникают когда:
— система растет слишком быстро долг не успевают отдавать
— меняются требования и то что было вчера нормально становится никуда не годно
— проблема настолько глобальна, что затрагивает все и вся — тогда решение по ней принимает, а точнее не принимает менеджмент
Проблемы возникают когда:
— система растет слишком быстро долг не успевают отдавать
— меняются требования и то что было вчера нормально становится никуда не годно
— проблема настолько глобальна, что затрагивает все и вся — тогда решение по ней принимает, а точнее не принимает менеджмент
Именно.
Системная проблема возникает, когда менеджмент оторван от технологии и эксплуатации слишком сильно. Тогда менеджмент не видит эксплуатационных проблем или не адекватно оценивает их как «быстренько исправьте и побежали дальше». Если одновременно менеджмент должен гнать сроки, то отсупать разработка может только за счет качества — потому что его не видно. :) Тогда возникает кризис — разработка считает, что все плохо из-за менеджмента, а менеджмент думает, что разработка вечно ноет, а надо бежать.
Системная проблема возникает, когда менеджмент оторван от технологии и эксплуатации слишком сильно. Тогда менеджмент не видит эксплуатационных проблем или не адекватно оценивает их как «быстренько исправьте и побежали дальше». Если одновременно менеджмент должен гнать сроки, то отсупать разработка может только за счет качества — потому что его не видно. :) Тогда возникает кризис — разработка считает, что все плохо из-за менеджмента, а менеджмент думает, что разработка вечно ноет, а надо бежать.
Очень точно сказано.
Видимо, большинство разработчиков с хабра работают в ИТ-компаниях. И там о таких разрывах, как правило, речи не идет. Поэтому им так легко строить зависимости роста технологического долга от степени адекватности разработчика. Понятно, что в очень простом случае такая зависимость есть и, возможно, она даже прямая. Но в реальном мире все как всегда сложнее.
Вот пример из жизни: Продукт запущен в срок, но в тот момент, когда менеджмент объявляет, что собирается запустить продукт именно в этот срок, разработчики с опытом хватаются за головы и, в кои-то веки, становятся инициаторами многочисленный собраний по этому поводу. В результате всех споров и недопониманий часть из них просто уходит.
Потом несколько месяцев после запуска царит полный [цензура] и разработчики «без перерыва на сон» вносят тысячи правок на живую, чтобы «заработало хоть как-то». А потом менеджмент бьет себя в грудь и говорит «Ребята, мы сделали!», а ребята находятся в «активном поиске» новой работы, потому что никто не хочет поддерживать «это», потому что понимают, что развивать «это» нереально. Нужно практически в буквальном смысле делать все заново. А на это, конечно, никто ни времени, ни ресурсов не даст. И менеджмент искренне недоумевает, почему разработчики недовольны и уходят. Ведь «Все работает! Чуть-чуть тут допилить, чуть-чуть там, а так все работает!», а на их место приходят новые, и первое время с легкостью выносят приговоры о компетентности предыдущих, потому что еще не понимаю куда попали.
А самое смешное в том, что этот продукт разрабатывался на смену старому «с косой-кривой» архитектурой, который невозможно было ни поддерживать ни развивать под новые задачи. И разработчики сами продвигали идею его создания, бились лбами о стены, в попытках доказать его необходимость и рисовали прекрасные картины, какими «фишками» можно будет этот продукт попутно наделить.
В результате пришел менеджмент, поставил эти фишки во главу угла, поставил нереальные сроки и начал под них все гнать. И что на выходе? Точно такое же говно, как и было. В чем-то превосходящее, в чем-то уступающее. Но в целом, такое же говно, вонючее и жиденькое. И никому не хочется брать его в руки и что-то из него лепить. Не более чем через полгода в отделе разработки не останется ни одного человека, который был бы свидетелем всех этих событий. И все пойдет по кругу.
Видимо, большинство разработчиков с хабра работают в ИТ-компаниях. И там о таких разрывах, как правило, речи не идет. Поэтому им так легко строить зависимости роста технологического долга от степени адекватности разработчика. Понятно, что в очень простом случае такая зависимость есть и, возможно, она даже прямая. Но в реальном мире все как всегда сложнее.
Вот пример из жизни: Продукт запущен в срок, но в тот момент, когда менеджмент объявляет, что собирается запустить продукт именно в этот срок, разработчики с опытом хватаются за головы и, в кои-то веки, становятся инициаторами многочисленный собраний по этому поводу. В результате всех споров и недопониманий часть из них просто уходит.
Потом несколько месяцев после запуска царит полный [цензура] и разработчики «без перерыва на сон» вносят тысячи правок на живую, чтобы «заработало хоть как-то». А потом менеджмент бьет себя в грудь и говорит «Ребята, мы сделали!», а ребята находятся в «активном поиске» новой работы, потому что никто не хочет поддерживать «это», потому что понимают, что развивать «это» нереально. Нужно практически в буквальном смысле делать все заново. А на это, конечно, никто ни времени, ни ресурсов не даст. И менеджмент искренне недоумевает, почему разработчики недовольны и уходят. Ведь «Все работает! Чуть-чуть тут допилить, чуть-чуть там, а так все работает!», а на их место приходят новые, и первое время с легкостью выносят приговоры о компетентности предыдущих, потому что еще не понимаю куда попали.
А самое смешное в том, что этот продукт разрабатывался на смену старому «с косой-кривой» архитектурой, который невозможно было ни поддерживать ни развивать под новые задачи. И разработчики сами продвигали идею его создания, бились лбами о стены, в попытках доказать его необходимость и рисовали прекрасные картины, какими «фишками» можно будет этот продукт попутно наделить.
В результате пришел менеджмент, поставил эти фишки во главу угла, поставил нереальные сроки и начал под них все гнать. И что на выходе? Точно такое же говно, как и было. В чем-то превосходящее, в чем-то уступающее. Но в целом, такое же говно, вонючее и жиденькое. И никому не хочется брать его в руки и что-то из него лепить. Не более чем через полгода в отделе разработки не останется ни одного человека, который был бы свидетелем всех этих событий. И все пойдет по кругу.
Черт, хотел эту статью перевести.
Вы меня опередили :)
Вы меня опередили :)
Мне кажется, ответственность за технологический долг несут две стороны:
1. Технари, которые реализуют неоптимальные решения
2. Менеджеры, которые не дают времени/ресурсов сначала на наём хороших сотрудников, потом на более тщательную реализацию, а затем не признают и не принимают вовремя необходимость доработок.
Поэтому, парным программированием и разработчиками этот долг не закрыть.
1. Технари, которые реализуют неоптимальные решения
2. Менеджеры, которые не дают времени/ресурсов сначала на наём хороших сотрудников, потом на более тщательную реализацию, а затем не признают и не принимают вовремя необходимость доработок.
Поэтому, парным программированием и разработчиками этот долг не закрыть.
Оптимальной работа будет тогда, когда руководитель ПО и менеджмент знает когда можно допустить технический долг и когда его нужно отдать. Программисты же часто поступают непрагматично с точки зрения бизнеса, например, пишут уж слишком чистый код.
По-моему, пример RIM в качестве иллюстрации опасности технического долга не годится и только вводит в заблуждение. Особенно в сочетании с советами насчет «парного программирования», т.к. провал RIM случился вследствие стратегических ошибок руководства компании.
Когда вышел первый iPhone, стало очевидно, что это гаджет следующего поколения с операционной системой другого типа и революционным интерфейсом. Но руководство RIM не ожидало быстрой потери рыночной доли и слишком долго продолжало сидеть на старой базе. В отличие от супергигантов, вроде Microsoft, Rim — относительно небольшая монопрофильная компания, у которой почти нет шансов догнать лидеров, засидевшись на старте. Из-за схожей причины неуспевания HP провалила запуск своих гаджетов на довольно хорошей WebOS.
Когда вышел первый iPhone, стало очевидно, что это гаджет следующего поколения с операционной системой другого типа и революционным интерфейсом. Но руководство RIM не ожидало быстрой потери рыночной доли и слишком долго продолжало сидеть на старой базе. В отличие от супергигантов, вроде Microsoft, Rim — относительно небольшая монопрофильная компания, у которой почти нет шансов догнать лидеров, засидевшись на старте. Из-за схожей причины неуспевания HP провалила запуск своих гаджетов на довольно хорошей WebOS.
Нанять правильных людей, тоже не достаточно для решения проблемы, ибо некоторые, даже очень зеленые, программисты считают что все делают «правильно».
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
(с) bash.im/quote/420672
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
(с) bash.im/quote/420672
Кто-то злой поставил минус, а между прочим картина весьма реалистичная. Едва ли не большинство доминирующих продуктов сделаны криво и косо, все ругаются, но терпят. А тщательно продуманные и вылизанные архитектуры умирают из-за
— «пока добежим, все вкусное съездят» — продукт готов, а рынок занят.
— инвестор не вытерпел, деньги кончились. не у каждого есть терпеливый и верный инвестор.
— заплутали в идеалах. сделали все правильно, не учли нюанс, переделали еще раз правильно, еще раз не учли, еще раз переделали. запутались, умерли.
— изменились требования. «пока расчет производился, объект расчета в норке скрылся»
— «пока добежим, все вкусное съездят» — продукт готов, а рынок занят.
— инвестор не вытерпел, деньги кончились. не у каждого есть терпеливый и верный инвестор.
— заплутали в идеалах. сделали все правильно, не учли нюанс, переделали еще раз правильно, еще раз не учли, еще раз переделали. запутались, умерли.
— изменились требования. «пока расчет производился, объект расчета в норке скрылся»
Технический долг совершенно нормален для любого живого проекта. «Девелопмент в рассрочку» — мы это называли так. Ценность получим сейчас, а проблемы отложим на потом.
Как любой долг, оно требует уплаты процентов. И если платить рассрочку не напряжно или проценты окупаются ранее полученной ценностью — то все нормально. А вот когда вся зарплата уходит на гашение кредитов — тут полный швах. А еще хуже — если на уплату одних процентов, даже без основного долга (как в историях про «русский стандарт») — это швах в квадрате. Вопрос гигиены, не более того. :)
Сам долг лучше бы мерить в количестве постоянных (recurrent) проблем, а не субъективном качестве кода. Я несколько раз наблюдал (и организовывал) смену команды разработчиков на проекте — и для всех живых проектов, абсолютно ВСЕГДА новые разработчики характеризовали старый код как «клоаку». Даже если команду сменить повторно — третья команда охарактеризует как «клоаку» творчество второй. :) Был даже пример обратной передачи — угадайте, что говорит первая команда про «что вы тут без нас наворотили?» :)
Как любой долг, оно требует уплаты процентов. И если платить рассрочку не напряжно или проценты окупаются ранее полученной ценностью — то все нормально. А вот когда вся зарплата уходит на гашение кредитов — тут полный швах. А еще хуже — если на уплату одних процентов, даже без основного долга (как в историях про «русский стандарт») — это швах в квадрате. Вопрос гигиены, не более того. :)
Сам долг лучше бы мерить в количестве постоянных (recurrent) проблем, а не субъективном качестве кода. Я несколько раз наблюдал (и организовывал) смену команды разработчиков на проекте — и для всех живых проектов, абсолютно ВСЕГДА новые разработчики характеризовали старый код как «клоаку». Даже если команду сменить повторно — третья команда охарактеризует как «клоаку» творчество второй. :) Был даже пример обратной передачи — угадайте, что говорит первая команда про «что вы тут без нас наворотили?» :)
Sign up to leave a comment.
Технический долг разорит вас. Если вы позволите, конечно