Comments 17
В смысле, вы строками кода измеряете программные продукты и те риски для больших организаций, которые они понесут в случае если программист ошибется? KPI сами по себе никому не нужны, хоть в вакууме, хоть в продакшене. А любая система KPI скажет, что да, 10 недель это понятный срок, при означенных исходных.
www.construx.com/Resources/Construx_Estimate_Download — ради интереса скачайте, вбейте «дано» задачи в софтину от (самого) Макконнела. Посмотрите результат…
www.construx.com/Resources/Construx_Estimate_Download — ради интереса скачайте, вбейте «дано» задачи в софтину от (самого) Макконнела. Посмотрите результат…
Мне кажется, что должна быть корреляция между количеством добавленных/измененных строк кода и количеством времени необходимого для этого.
+ так же я наблюдаю отход от деталей по мере дряхления конторы. всё больше начинаются какие-то пространные разговоры о потенциальных рисках. Всё меньше и меньше людей открывает код. Оценки только растут и из-за этого рушатся бизнес кейсы, проэкты умирают не начавшись, а могли бы приносить прибыль.
я вот думаю: как с этим бороться?
+ так же я наблюдаю отход от деталей по мере дряхления конторы. всё больше начинаются какие-то пространные разговоры о потенциальных рисках. Всё меньше и меньше людей открывает код. Оценки только растут и из-за этого рушатся бизнес кейсы, проэкты умирают не начавшись, а могли бы приносить прибыль.
я вот думаю: как с этим бороться?
Это не побороть единолично(конечно если вы не директор конторы)…
Вот вам мой анти-паттерн дряхлой конторы, где ведение документации и апрув внесения изменений, это далеко не самое узкое место:
— огромная система которая включает биллинг, систему рассылки, контроля задач для рабочих, внутренний портал, и многое другое, — всего около 50 приложений. Писалось начиная с 2000-х, кучкой различных контор. Часть реализована на Java+Oracle, а другая часть на .NET+MS SQL. Эти части связаны как посредством вебсервисов так и OLE DB. В итоге баги в Java части влекут за собой баги в .NET части. Также используются 3rd party вебсервисы.
— полу-сотня баз данных на паре десятков SQL серверов и запущенных на них с SQL агентов, которые выполняют до полутысячи job-ов, и никто не знает, где что используется и кому это надо.
— система контроля версий морально устаревшая и использовалась сугубо для хранения (барабанная дробь...) zip ????
попытки внедрить хотя бы SVN закончились тем, что изменения продолжают деплоиться без коммита, в результате часть кода в SVN уже утратила актуальность. Зато в теперь SVN стали появляться бинарники))).
— отрывочная документация к частям махины кусками разбросана на файл-сервере. Юнит-тестов нет, тест-кейсов тоже нет. Хранителей знаний о системе практически не осталось из-за текучки кадров.
Как с этим бороться, я тоже не представляю.
Вот вам мой анти-паттерн дряхлой конторы, где ведение документации и апрув внесения изменений, это далеко не самое узкое место:
— огромная система которая включает биллинг, систему рассылки, контроля задач для рабочих, внутренний портал, и многое другое, — всего около 50 приложений. Писалось начиная с 2000-х, кучкой различных контор. Часть реализована на Java+Oracle, а другая часть на .NET+MS SQL. Эти части связаны как посредством вебсервисов так и OLE DB. В итоге баги в Java части влекут за собой баги в .NET части. Также используются 3rd party вебсервисы.
— полу-сотня баз данных на паре десятков SQL серверов и запущенных на них с SQL агентов, которые выполняют до полутысячи job-ов, и никто не знает, где что используется и кому это надо.
— система контроля версий морально устаревшая и использовалась сугубо для хранения (барабанная дробь...) zip ????
попытки внедрить хотя бы SVN закончились тем, что изменения продолжают деплоиться без коммита, в результате часть кода в SVN уже утратила актуальность. Зато в теперь SVN стали появляться бинарники))).
— отрывочная документация к частям махины кусками разбросана на файл-сервере. Юнит-тестов нет, тест-кейсов тоже нет. Хранителей знаний о системе практически не осталось из-за текучки кадров.
Как с этим бороться, я тоже не представляю.
Мне кажется, что должна быть корреляция между количеством добавленных/измененных строк кода и количеством времени необходимого для этого.Корреляция есть, но она обратная. Написать новый сервис не пару тысяч строк кода проще, чем добавить пару десятков строк в существующий. :)
А разве есть что-то в этом удивительное? :)
Дано:
Изменения, такого рода могут быть очень опасны в живой системе, особенно завязанной на живые деньги. Особенно на чужие.
Кто и что когда-то делал из ныне живущих, так понимаю, досконально не знает никто и что будет после изменения достоверно сказать, со всей полнотой ответственности, тоже желающих, полагаю, не так много.
Если программа будет просто выбрасывать исключение — это будет просто прекрасно.
В данном конкретном случае, кто даст гарантию, что чьи-то умелые руки когда-то не поленились обойтись IF-ом вместо SWITCH-а (руководствуясь логикой: ну а чё, если не OBJECT_A то OBJECT_B тогда по-любому). И о том, что-то пошло не так мы рискуем узнать только тогда, когда нам кто-то выкатит судебный иск по компенсации ущерба, нанесенного неправильной работой программы. Если программа выкидывает исключения — это не беда, вот если она работает неправильно — вот это уже катастрофа.
Одна из особенностей таких монструозных систем — это обилие различных групп(часто международных), которые ее на протяжении всего срока жизни развивали. И один из механизмов защиты от кривых рук(в том числе своих собственных) чтоб не порушить другие части системы при разработке нового функционала — это метод copy-paste кода. Делается это по той же самой причине, что озвучена выше. А потом, когда уже уже пропадает понимание полной картины остается только один принцип — «Не навреди». Делайте что угодно, но только не порушьте то что есть. На этом этапе мы тогда забываем про все принципы программирования вместе взятые и изобретаются костыли невиданной красоты и хитроумности.
И живет этот чемодан без ручки до тех пор пока «либо ишак не подохнет, либо падишах». Ну а потом, если задача все еще актуальна, она решается с нуля заново и все повторяется снова.
И в этом нет ничего плохого. Просто естественный цикл жизни некоторого класса корпоративных продуктов.
Так, что никакой корреляции между количеством кода и временем его появления в релизе я бы не искал.
Дано:
Несколько ХХ млн строчек кода, много харда, несколько 10ков лет жизни.
Изменения, такого рода могут быть очень опасны в живой системе, особенно завязанной на живые деньги. Особенно на чужие.
Кто и что когда-то делал из ныне живущих, так понимаю, досконально не знает никто и что будет после изменения достоверно сказать, со всей полнотой ответственности, тоже желающих, полагаю, не так много.
Если программа будет просто выбрасывать исключение — это будет просто прекрасно.
В данном конкретном случае, кто даст гарантию, что чьи-то умелые руки когда-то не поленились обойтись IF-ом вместо SWITCH-а (руководствуясь логикой: ну а чё, если не OBJECT_A то OBJECT_B тогда по-любому). И о том, что-то пошло не так мы рискуем узнать только тогда, когда нам кто-то выкатит судебный иск по компенсации ущерба, нанесенного неправильной работой программы. Если программа выкидывает исключения — это не беда, вот если она работает неправильно — вот это уже катастрофа.
Одна из особенностей таких монструозных систем — это обилие различных групп(часто международных), которые ее на протяжении всего срока жизни развивали. И один из механизмов защиты от кривых рук(в том числе своих собственных) чтоб не порушить другие части системы при разработке нового функционала — это метод copy-paste кода. Делается это по той же самой причине, что озвучена выше. А потом, когда уже уже пропадает понимание полной картины остается только один принцип — «Не навреди». Делайте что угодно, но только не порушьте то что есть. На этом этапе мы тогда забываем про все принципы программирования вместе взятые и изобретаются костыли невиданной красоты и хитроумности.
И живет этот чемодан без ручки до тех пор пока «либо ишак не подохнет, либо падишах». Ну а потом, если задача все еще актуальна, она решается с нуля заново и все повторяется снова.
И в этом нет ничего плохого. Просто естественный цикл жизни некоторого класса корпоративных продуктов.
Так, что никакой корреляции между количеством кода и временем его появления в релизе я бы не искал.
т.е. нет способов бороться с прогрессирующей дряхлостью компании? И от развала большую контору никто не удержит? не придумано способов?
Ведь видны симптомы сейчас: отсутствие знаний (очень много новых людей) -> монструозные оценки работы-> осваивание всех средств (и наём ещё больше новых людей)->никаких lessons learned
именно поэтому я пытаюсь найти метрики, чтобы можно было показать людям выше: это ненормально. нельзя соглашаться с оценкой 100К, платить, и получать назад пару строк кода.
Ведь видны симптомы сейчас: отсутствие знаний (очень много новых людей) -> монструозные оценки работы-> осваивание всех средств (и наём ещё больше новых людей)->никаких lessons learned
именно поэтому я пытаюсь найти метрики, чтобы можно было показать людям выше: это ненормально. нельзя соглашаться с оценкой 100К, платить, и получать назад пару строк кода.
Способы, наверное, есть. Но универсального решения, с определенного этапа, я думаю, что не существует.
То что я описал в своем комментарии — это тоже реальный пример из одной транснациональной финансовой корпорации на примере реально существующего продукта. Симптоматика, как видите, схожая.
Проблема в том, что из-за естественной текучки и устаревания технологий ценность даже простых изменений со временем возрастает. Это, примерно, как сейчас ремонтировать ламповый телевизор, собранный каким-нибудь «кулибиным».
К сожалению, или к счастью, но жизнь такова, что это абсолютно нормально.
Как говорится, «мал золотник, да дорог» :) Тут скорее важно понимание того, почему одна строка кода за 100К это много, или мало. Если аргументацию удастся представить в долларовом эквиваленте, тогда есть шанс, что к ней прислушаются.
Единственное, что можно сделать — это как-то оптимизировать те этапы процесса разработки, на которые вы в состоянии повлиять, а на то что повлиять не можете(даже если вас воротит от этого) — просто примите как данность. Это ведь просто работа.
То что я описал в своем комментарии — это тоже реальный пример из одной транснациональной финансовой корпорации на примере реально существующего продукта. Симптоматика, как видите, схожая.
Проблема в том, что из-за естественной текучки и устаревания технологий ценность даже простых изменений со временем возрастает. Это, примерно, как сейчас ремонтировать ламповый телевизор, собранный каким-нибудь «кулибиным».
это ненормально. нельзя соглашаться с оценкой 100К, платить, и получать назад пару строк кода.
К сожалению, или к счастью, но жизнь такова, что это абсолютно нормально.
Как говорится, «мал золотник, да дорог» :) Тут скорее важно понимание того, почему одна строка кода за 100К это много, или мало. Если аргументацию удастся представить в долларовом эквиваленте, тогда есть шанс, что к ней прислушаются.
Единственное, что можно сделать — это как-то оптимизировать те этапы процесса разработки, на которые вы в состоянии повлиять, а на то что повлиять не можете(даже если вас воротит от этого) — просто примите как данность. Это ведь просто работа.
да это, действительно, только работа :) Но очень нравится контора и не хочется уходить.
но вот с притчей — не согласен! В том что происходит сейчас: оценки растут не от большого знания, а от большого незнания. начиная от новичков за клавиатурой, пытающихся понять все эти копи-пэйстет куски, окруженные тысячами IF до множество разнокалиберных менеджеров — везде огромные оверхеды из-за отсутствия знания. огромные маржины просто из-за страха неизвестного.
как бороться с незнанием?
не отпускать старых работников?
не нанимать новых?
я пытаюсь преследовать: автоматизировать и визуализировать аспект «а что мы вообще делаем? и понимаем ли сколько денег тратится?»
но вот с притчей — не согласен! В том что происходит сейчас: оценки растут не от большого знания, а от большого незнания. начиная от новичков за клавиатурой, пытающихся понять все эти копи-пэйстет куски, окруженные тысячами IF до множество разнокалиберных менеджеров — везде огромные оверхеды из-за отсутствия знания. огромные маржины просто из-за страха неизвестного.
как бороться с незнанием?
не отпускать старых работников?
не нанимать новых?
я пытаюсь преследовать: автоматизировать и визуализировать аспект «а что мы вообще делаем? и понимаем ли сколько денег тратится?»
Ну уходить, действительно, не нужно. Тем более если нравится.
На самом деле противоречия с притчей и в вашем случае нет. Там просто речь о том, что у человека уже было нужное знание, а в вашем случае это знание приходится получать в процессе. Но суть в том, что ценность его и в том и в другом случае существенная.
С незнанием можно бороться только обучением. А минимизация текучки — это очень комплексный вопрос, начиная от первого интервью с HR и заканчивая кофе-машинами на кухне. Но вы, судя по всему, и так уже все делаете правильно.
На самом деле противоречия с притчей и в вашем случае нет. Там просто речь о том, что у человека уже было нужное знание, а в вашем случае это знание приходится получать в процессе. Но суть в том, что ценность его и в том и в другом случае существенная.
С незнанием можно бороться только обучением. А минимизация текучки — это очень комплексный вопрос, начиная от первого интервью с HR и заканчивая кофе-машинами на кухне. Но вы, судя по всему, и так уже все делаете правильно.
т.е. нет способов бороться с прогрессирующей дряхлостью компании?
Так проблема в продукте, не в компании. В той же компании можно начать новый продукт и до первого релиза делать хоть 100 изменений в день.
Рефакторинг.
Накодить паралельно с нуля продукт, решающий эти же задачи.
А как вы делаете новый функционал если 10 недель на строчку?
Или клиенты просят, а вы не делаете.
Накодить паралельно с нуля продукт, решающий эти же задачи.
А как вы делаете новый функционал если 10 недель на строчку?
Или клиенты просят, а вы не делаете.
Я удивлен, что никто еще не спросил про break и про то, сколько времени займет исправление…
www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351 — тут нашел о строках кода! :)
даже в привью на амазоне можно глянуть на стр 62
даже в привью на амазоне можно глянуть на стр 62
ну собственно так и есть, нашли мы недавно ошибку в компиляторе С++/CLI, из за чего одна из конструкций просто не работает…
Что нам ответили в MS — поймите сделать это работающим стоит несколько сотен тысяч, а так как это второй случай когда обращаются по этой проблеме…
И реально там шла переписка, большинство из ответственных просто не в курсе о существовании подобного, и реально включают кучу времени что бы просто разобраться о чем идет речь.
Хотя по сути изменение реально похожее на пример выше, в пределах нескольких строк кода, всего лишь правильно генерировать код на имеющийся атрибут, т.е. привести компилятор к тому что бы он работал как задумано.
Что нам ответили в MS — поймите сделать это работающим стоит несколько сотен тысяч, а так как это второй случай когда обращаются по этой проблеме…
И реально там шла переписка, большинство из ответственных просто не в курсе о существовании подобного, и реально включают кучу времени что бы просто разобраться о чем идет речь.
Хотя по сути изменение реально похожее на пример выше, в пределах нескольких строк кода, всего лишь правильно генерировать код на имеющийся атрибут, т.е. привести компилятор к тому что бы он работал как задумано.
Sign up to leave a comment.
Сколько нужно минут, чтобы добавить 1 строчку кода в большой организации?