Читал и ловил Вьетнамские флешбеки с прошлых работ. Когда стал постарше, то понял на своем опыте, что великие вещи могут создаваться и без переработок.
Кстати, сложный и комплексный софт разрабатывали и в прошлом веке, но тогда кранчей почти не было. А появились они как раз в конце девяностых - начале 2000-х. А знаете почему? Потому что именно в это время появилась такая вещь как Agile и другие современные Buzz words, которые знает каждый программист. С того момента всякое планирование, распределение нагрузки, календари разработки, features диаграммы и т.п. исчезло как вид :D
Ну да, в 90-ых был популярный RAD, в середине 90-ых появился Scrum и XP, и как раз в 2001 году появился этот самый манифест Agile, подписанный достаточно значимыми людьми, и вот тут уже понеслось гавно по трубам в полную мощь. Странным образом в начале 2000-ых как раз наметилась и начала усиливаться тенденция, которая привела к тому, что нонче уже стало нормальным прочитать обзор в стиле: "Ну да Cyberpunk отличная игра, только баги в каждой миссии из-за которых играть невозможно, 90/100", стали нормой патчи первого дня и прочие радости жизни.
Но на самом деле далеко не все перебрались на Agile. Вот буквально год назад спорил со знакомым погроммистым, который мне доказывал, что Agile это круто на примере своей конторы, как они все круто успевают в срок и без глюков благодаря Agile. Однако после разбора их бизнес-процессов, оказалось что у них, ну вот самый такой обыкновенный "Водопад" из 60-ых :-)
Сам-то я правда сторонники итеративной разработки, которую также опровобовали еще в 60-ых годах на программе Меркурий (а вот Аппооллон это чистый "Водопад"), и которая описана в MIL-STD-498 и EIA J-STD-016. И вроде бы как итеративная модель разработка всегда пристсвует в стратегиях Agile, ан нет, дьявол кроется в деталях, а именно в реализациях конкретнтных методологий. Одну из самых неприятных особенностей Agile, а конкретно Scrum, их тех что я наблюдал - это короткие спринты, которые так обожают манагеры, и которые в итоге приводят к тому что погроммисты безконтрольно вхерачивают фичи, причем самым кондовым образом, лишь бы успеть: никто не будет анализировать, искать лучшие решения, а потом просто перейдут к следующему пункту, и в итоге технический долг накапливается и накапливается, а код сука становится все более и более хрупким... Вторая проблема гибкого подхода — внезапно, клиентоориентированность, а конкретно, адаптация под изменяющиеся требования заказчика, что лучше всего раскрывается в b2b, когда в итоге нихрена никто, ни разработчики, ни заказчики, не понимают чего они должны получить на выходе, а распланировать и написать нормальное ТЗ всем впадлу, lol :-) Самое же кринжовое что я видел — это экстремальное программирование, ака XP. В то время как, например, тот же Kanaban уже мало чем отличается от обыкновенного заводского способа: взял металлическую болванку со склада, выточил из нея железный хер на токарном станке и передал свое творение дальше по участкам, а они уже дальше пусть ипуться с ним как хотят :-) И так повторять 8 часов в день, 5 дней в неделю, 4 недели в месяце и т.д. и т.п. пока склад не опустеет (а он не опустеет никогда).
Самое забавно, что в общем-то все оптимальные бизнес процессы так или иначе описываются каскадной, итеративной и инкрементальной моделями, а также их комбинациями. В общем не сильно то много подходов, куда важнее конкретные процедуры и best practices, которые должны появляться в результате жесткой конкуренции, причем это вообще-то должны быть конкретные технологические карты сподробным описанием операций как для тупых: взять херовину X, вставить в разъем Y, перевернуть и т.д. Но нет, все пошли по братному пути: "философия", "концепция" и прочая хрень с евангелистами и коучерами. В итоге вся эта сектанская возня с методологиями разработки программного обеспечения на мой взгляд вылилась в хроническую нечестую конкуренцию — при разработке начинают экономить на всем: на анализе, планировании, составлении расписаний, документации, поиску альтернативных решений, сложном тестировании, а главным становится херачить код по каждому поводу когда у заказчика левая пятка зачесалась. Естетсвенно приходиться прибегать к самыми жестким приемам нечестной коункуренции: кранчам, эксплуатации и привличению дешевых code monkeys из Зимбабве, и вуаля, у потребителей создается впечатление что за дешево и быстро они получили супер-пупер продукт. Правда супер-пупер продуктом это кажется до первой тесной работы, когда выясняется что все работает совсем не так или вообще никак не работает, и начинаются переделки, допливание и так по кругу, и на выходе в итоге получаем супер-раздутые бюджеты без гарантии, что ПО таки заработает и будет востребовано. Естетсвенно в таких условиях честно конкурировать могут немногие, ибо пока Васян целый год анализирует, проектирует, пилит, тестироует и выпускает готовый продукт, какой-нибудь Толян за 3 месяца , хуяк-хуяк и в продакшен....полуфабрикат собранный на коленках, но так как мало кто умеет в долгосрочное планирование, то найдется много желающих оплатить Санта-Барбару от Толяна лет на 5 :-)
Причем они еще и дальше продолжают выдумывать псевдо-методолгии и псевдо-парадигмы (главное — это модные слова и никогда не останавливаться!), например DevOps, для которого иногда встречаются графические презентации из хорошо известного шаблона мемов :-)
Ну и еще одна болезн, которая походу передается воздушно-капельным путем: вот прям повально люди дрочат почему-то именно на процессы, а не на конкретный результат (например, а давайте сделам 100% покрытие тестов, а потом обнаружим, что тесты не те и один хер не работает как надо), в общем карго-культы. такие карго-культы.
Читал и ловил Вьетнамские флешбеки с прошлых работ. Когда стал постарше, то понял на своем опыте, что великие вещи могут создаваться и без переработок.
Кстати, сложный и комплексный софт разрабатывали и в прошлом веке, но тогда кранчей почти не было. А появились они как раз в конце девяностых - начале 2000-х. А знаете почему? Потому что именно в это время появилась такая вещь как Agile и другие современные Buzz words, которые знает каждый программист. С того момента всякое планирование, распределение нагрузки, календари разработки, features диаграммы и т.п. исчезло как вид :D
Ну да, в 90-ых был популярный RAD, в середине 90-ых появился Scrum и XP, и как раз в 2001 году появился этот самый манифест Agile, подписанный достаточно значимыми людьми, и вот тут уже понеслось гавно по трубам в полную мощь. Странным образом в начале 2000-ых как раз наметилась и начала усиливаться тенденция, которая привела к тому, что нонче уже стало нормальным прочитать обзор в стиле: "Ну да Cyberpunk отличная игра, только баги в каждой миссии из-за которых играть невозможно, 90/100", стали нормой патчи первого дня и прочие радости жизни.
Но на самом деле далеко не все перебрались на Agile. Вот буквально год назад спорил со знакомым погроммистым, который мне доказывал, что Agile это круто на примере своей конторы, как они все круто успевают в срок и без глюков благодаря Agile. Однако после разбора их бизнес-процессов, оказалось что у них, ну вот самый такой обыкновенный "Водопад" из 60-ых :-)
Сам-то я правда сторонники итеративной разработки, которую также опровобовали еще в 60-ых годах на программе Меркурий (а вот Аппооллон это чистый "Водопад"), и которая описана в MIL-STD-498 и EIA J-STD-016. И вроде бы как итеративная модель разработка всегда пристсвует в стратегиях Agile, ан нет, дьявол кроется в деталях, а именно в реализациях конкретнтных методологий. Одну из самых неприятных особенностей Agile, а конкретно Scrum, их тех что я наблюдал - это короткие спринты, которые так обожают манагеры, и которые в итоге приводят к тому что погроммисты безконтрольно вхерачивают фичи, причем самым кондовым образом, лишь бы успеть: никто не будет анализировать, искать лучшие решения, а потом просто перейдут к следующему пункту, и в итоге технический долг накапливается и накапливается, а код сука становится все более и более хрупким... Вторая проблема гибкого подхода — внезапно, клиентоориентированность, а конкретно, адаптация под изменяющиеся требования заказчика, что лучше всего раскрывается в b2b, когда в итоге нихрена никто, ни разработчики, ни заказчики, не понимают чего они должны получить на выходе, а распланировать и написать нормальное ТЗ всем впадлу, lol :-) Самое же кринжовое что я видел — это экстремальное программирование, ака XP. В то время как, например, тот же Kanaban уже мало чем отличается от обыкновенного заводского способа: взял металлическую болванку со склада, выточил из нея железный хер на токарном станке и передал свое творение дальше по участкам, а они уже дальше пусть ипуться с ним как хотят :-) И так повторять 8 часов в день, 5 дней в неделю, 4 недели в месяце и т.д. и т.п. пока склад не опустеет (а он не опустеет никогда).
Самое забавно, что в общем-то все оптимальные бизнес процессы так или иначе описываются каскадной, итеративной и инкрементальной моделями, а также их комбинациями. В общем не сильно то много подходов, куда важнее конкретные процедуры и best practices, которые должны появляться в результате жесткой конкуренции, причем это вообще-то должны быть конкретные технологические карты сподробным описанием операций как для тупых: взять херовину X, вставить в разъем Y, перевернуть и т.д. Но нет, все пошли по братному пути: "философия", "концепция" и прочая хрень с евангелистами и коучерами. В итоге вся эта сектанская возня с методологиями разработки программного обеспечения на мой взгляд вылилась в хроническую нечестую конкуренцию — при разработке начинают экономить на всем: на анализе, планировании, составлении расписаний, документации, поиску альтернативных решений, сложном тестировании, а главным становится херачить код по каждому поводу когда у заказчика левая пятка зачесалась. Естетсвенно приходиться прибегать к самыми жестким приемам нечестной коункуренции: кранчам, эксплуатации и привличению дешевых code monkeys из Зимбабве, и вуаля, у потребителей создается впечатление что за дешево и быстро они получили супер-пупер продукт. Правда супер-пупер продуктом это кажется до первой тесной работы, когда выясняется что все работает совсем не так или вообще никак не работает, и начинаются переделки, допливание и так по кругу, и на выходе в итоге получаем супер-раздутые бюджеты без гарантии, что ПО таки заработает и будет востребовано. Естетсвенно в таких условиях честно конкурировать могут немногие, ибо пока Васян целый год анализирует, проектирует, пилит, тестироует и выпускает готовый продукт, какой-нибудь Толян за 3 месяца , хуяк-хуяк и в продакшен....полуфабрикат собранный на коленках, но так как мало кто умеет в долгосрочное планирование, то найдется много желающих оплатить Санта-Барбару от Толяна лет на 5 :-)
Причем они еще и дальше продолжают выдумывать псевдо-методолгии и псевдо-парадигмы (главное — это модные слова и никогда не останавливаться!), например DevOps, для которого иногда встречаются графические презентации из хорошо известного шаблона мемов :-)
Самое херовое, что похоже этот рак стал добираться и до life critical приложух
https://en.wikipedia.org/wiki/Boeing_737_MAX_groundings
Ну и еще одна болезн, которая походу передается воздушно-капельным путем: вот прям повально люди дрочат почему-то именно на процессы, а не на конкретный результат (например, а давайте сделам 100% покрытие тестов, а потом обнаружим, что тесты не те и один хер не работает как надо), в общем карго-культы. такие карго-культы.