Комментарии 42
Области применения и типы программ бывают разные, поэтому общего подхода нет.
Если, например, вы, как Возняк, имеете целью уместить программу-монитор в 2 килобайта ПЗУ Apple II, то простота модификации вообще не принимается во внимание.
У программирования нет цели - только путь!
Если бы авторы статей с минусами попробовали подумать, а почему так, то наверное они смогди бы написать статью, которую бы плюсовали
Но, совершенно случайно и необьяснимо один и те де "идеи" заслуженно минусятся
Про "легкость изменения кода" - это просто одно из многих нефункциональных требований, которые могут ввдвигаться, а могу и нет
И да, хорошо спроектированный код обычно легче править, это "бонус"
Я вижу эту статью, как не совсем корректное применение идеи Абрахама Маслоу к коммерческому программированию. Почему не совсем корректное - потому, что в изначальной идее фундаментом являются безусловные предпосылки личности каждого. В идее статьи смешались бизнес задачи владельца бизнеса и его безусловные стремления и задачи программиста, и не важно, если это одна и та же персона.
Но не суть. Если допустить таки идею, что идея пирамиды потребностей применима, то становится понятно, что закладывал автор:
В Пирамиде Маслоу есть несколько уровней и, казалось бы, обеспечил себя жратвой и потомством, и остановись, но нет - сытому и размножившемуся индивиду надо уже развитие и признание.
Так и в идее статьи автор, предположительно, хочет добавить другие потребности, какие должны быть удовлетворены, после удовлетворения потребностей бизнеса.
И именно тут и кроется нестыковка. Задачи бизнеса достигнуты - остановись. Это бизнес проект а не личность. Но нет, давайте добавим тестирование и простой саппорт, как надстройку к потребностям. Хотя на самом деле - эти задачи тоже должны быть задачами бизнеса, поскольку, как и было разумно отмечено в комментариях, не каждому бизнесу это надо. Например, я пишу MVP для проверки бизнес идеи. Прошло плохо - убил проект. Не рефакторнул, а просто отказался! О тестах и улучшении речи даже не идёт. Только так и работает в бизнесе, а в применении к личностям подобный подход, минимум, аморален. Хотя бы поэтому идея с потребностями не сработает в коммерческом программировании.
Ну наверно, просто есть ощущение, что автор еще толком не оказывался в мире, где есть ТЗ, definition of done, таски :)
Если же говорить о программировании не за деньги ... вообще логично применять те же принципы, что и в коммерческом, если интересует результат
IMHO, это всё относится к пункту Business. Всё, что вы перечислили (ТЗ, definition of done, таски) нацелено на создание кода, решающего определённую задачу.
В реальной жизни все остальное находится за пределами круга интересов программиста. Исключение - фрилансеры, которые все делают в одном лице.
Но тогда все еще проще. Есть проект создания программного продукта и некий цикл с артефактами. Условно:
идея
PoC
бюджетирование/планирование
получение финансов и ресурсов
написание требований
написание ТЗ
разработка
тестирование
пилот
допиливание
выход на рынок
Понятно этапы могут быть различными а может набежать 100500 знатоков методологий и прочего, но суть не в этом. Зачем натягивать заведемо иную концепцию, которая именно пирамида или матрешка, на известную всем процедуру разработки продукта?
Никакой матрешки в процессе создания продукта нет, это последовательно-итеративный процесс, о чем вам расскажет любой менеджер/продуктовик.
Основная же "идея" пирадимы Маслоу - мотивация человека в конкретный момент времени и пояснение, почему и как это происходит для разных людей.
Просто ... я могу еще объяснить все эти изыскания просто, но в чем-то обидно для программистов. Процесс создания продукта долог и участие программиста в нем не так велико, как ему кажется. Да, он делает абсолютно НЕОБХОДИМУЮ вещь, но с точки зрения timeline его участие довольно таки невелико. Вместо того, чтобы "философствовать" на тему, достаточно просто понять, что ты просто ВАЖНЫЙ участник сравнительно небольшого участка большого дела. И если хочешь понять, как и что - меняй роль и иди, в менеджеры/продуктовики, которые проходят весь путь от начала и до конца.
Но можно пытаться строить из себя мудреца, который пытается по капле узнать о существовании океана, если океан недалеко и до него можно дотопать ножками и посмотреть
Абсолютно с вами согласен, что точка зрения любого менеджера/продуктовика не должна совпадать с точкой зрения программиста. Но и наоборот тоже верно. Эта статья про написание кода, а не про разработку продукта. Для программистов, а не для менеджеров/продуктовиков. Но спасибо, что поделились своим мнением.
Эта статья про написание кода
Тогда стоило бы явно об этом сказать, как минимум. Мол, забиваем на все вокруг: бизнес, менеджеров, требования и говорим о сферическом написании кода в вакууме. Но нет. Этой оговорки тут не наблюдается
Вы считаете, что стоило об этом сказать явно, потому что люди в массе своей стали тупее? Я всё-таки верю в человеков и в их способности к обмену неформализованной информацией. Человек со средним интеллектом способен вытащить из поста информацию, что он всё-таки именно про написание кода, а не про разработку продукта. А если этого кто-то не понимает... ну, люди есть разные. Я, вон, тоже много чего не понимаю, но тоже не отказываю в себе в удовольствии поучить других, как и что им следовало бы делать.
Человек со средним интеллектом способен вытащить из поста информацию, что он всё-таки именно про написание кода,
Ну значит, мой интеллект ниже среднего) И мы уже с вами не раз обсуждали, что для меня утверждение, что "конечная цель программирования" подразумевает вообще какой-то код не кажется очевидной. Что если я программирую при помощи диаграмм? Что если я программирую таймер на розетке? Что если я программирую свою любимую мультиварку? Ни в одном из этих случаев я не пишу никакой код.
Пишите. Во всех трёх случаях. Только не на бумаге и не ручкой. Конечный результат программирования - это код. Так или иначе. В вашей Вселенной может быть как-то и по-другому, а в моей - вот так.
Вам помочь нагуглить программы работающие без кода? Видели когда-нибудь ткацкий станок, производящий узор? Как работает механический таймер розетки представляете? А как работает реле, которое при определенной температуре подает напряжение, а при другой - нет? Про Аду Лавлейс, в конце-то концов что-то слышали?
Вам помочь нагуглить программы работающие без кода?
Могу добавить к вашим примерам психику и тело - на протяжении жизни мы обретаем опыт, который складывается из множества подпрограмм с функциями, коэффициентами и условными переходами. Наши переживания, выборы, ловкость и усталость - следствие работы программ, которые мы изменяем ежедневно, не видя при этом ни строчки кода. В этих программах накапливаются ошибки, случаются переполнения и необходимость рефакторинга, поэтому люди ходят в спортзалы и к психотерапевтам, где более опытные "программисты" помогают наладить работу программно-аппаратного комплекса. И конечная цель такого "программирования" - прожить дольше, комфортнее и с пользой для мира, а не какой-то код, спрятанный в нейронах.
А в статье слишком вольно интерпретируется слово "цель" - по смыслу там больше подходят "объект", "предмет" или "инструмент". И если для "простейших потребностей" подходит "создать красивый код", то на вершине "пирамиды" ожидалось что-то вроде "работа программы создает пользу в реальном мире".
В конце концов, чтобы компьютер работал код вообще не обязателен. Это лишь удобная абстракция. Которой может не быть. Можно программировать подавая и убирая напряжение с транзисторов. Программа должна быть понятна ИСПОЛНИТЕЛЮ в первую очередь. Код создан для того, чтобы быть понятным людям. Что такое программа в общем смысле? Набор инструкций. Если я даю своей розетке понятный ей набор инструкций(которые не содержат код) я ее программирую. Если я задаю этот набор инструкций при помощи рычагов ткацкому станку - поздравляю, я сделал программу для ткацкого станка
Давайте вместе подумаем, в какое место на этой машине нужно написать код.
Более того, в статье вы постоянно утверждаете "Конечная цель программирования". Не написания кода, а именно программирования. А тупой в итоге я, потому что под программированием должен был понять именно то, что понимаете вы, догадаться)
Как по мне, статью заминусили по двум причинам. Первая — грубейшая логическая ошибка в первой же строчке, что, очевидно, не понравится аудитории IT-ресурса. Что есть программирование? Процесс создания компьютерной программы. Что есть компьютерная программа? Совокупность инструкций и данных, на основе которых аппаратное обеспечение выполняет требуемые действия. Таким образом конечная (то есть, основная, конкретизированная и измеримая) цель программирования — создание компьютерной программы, а не что-то другое.
Код может быть отвратительно спроектирован и плохо поддаваться дальнейшему обслуживанию, но при этом работать и выполнять действия, которые и должен был в соответствии с ожидаемым результатом, а значит, конечная цель была достигнута. Или же наоборот, все может быть написано "по феншую", но при этом программа будет выполнять совсем не те действия, которые от нее ожидались, или же не все из них, то есть, будет незавершенной, а значит, конечная цель в данном случае достигнута не была. Вот если бы автор начал с чего-то вроде: "Чем принципиально отличается хорошая архитектура от плохой?", а далее развил мысль про изменяемость кода, минусов было бы гораздо меньше.
Но они бы все равно были, поскольку автор что-то пытался сказать, но в итоге растекся мыслями по тексту. Много лирики и мало практики. Основная мысль в общем верна, но для опытного разработчика материал не имеет смысла, поскольку такой человек и так прекрасно знает, насколько важна простота сопровождения программы и к чему может привести фанатичное следование даже самым хорошим и правильным принципам проектирования, а для новичков там слишком мало фактического материала. Лонгрид для начинающих с большим количеством реальных кейсов обязательно бы собрал гору плюсов, как и статья про не самые очевидные ошибки проектирования с далеко идущими последствиями, ориентированная на матерых программистов. Полезные статьи сообщество любит и ценит.
Самое главное: прежде, чем спорить, неплохо бы договориться о терминах: что понимать под "конечной целью" и целью кого: заказчика, потребителя, программиста, мирового сообщества или кого-то еще. Цель - осознать, где и когда остановиться? Дойти до этой точки? А кто принимает решение? Или каким должен быть идеальный продукт в каждом конкретном случае? Разработка плана, как создавать идеальный продукт? Как перейти от зафиксированного продукта к процессу? Каким должен быть идеальный процесс разработки?
Конечная цель программирования - сам текст программы. Это настолько очевидно, что перестаёт восприниматься как конечная цель
Нередко оказывается, что пресловутая очевидность как раз мешает ясно взглянуть на что-то: мнение уже сформировано и не пересматривается.
Сначала по пирамидке: как у вас Business не оказался основанием? Уровень должен быть самодостаточным, т.е. иметь ценность без верхних, иначе это просто цепочка промежуточных этапов. Нельзя ведь начинать писать код, если не сформулированы хоть какие-то требования? Значит, ниже надо положить постановку задачи. Постановка задачи тоже в свою очередь чем-то будет заблокирована: например, бюджетом и подбором персонала, и так далее. А просто написанный, но неиспользуемый код сам по себе не имеет ценности, только потенциал.
Теперь по сути: имхо в вашей пирамидке не хватает настоящего основания: цели создания конкретной программы. Не универсальной цели, а конкретной для отдельно взятого случая. Посмотрим на примерах.
Для первого варианта положим в основу банальную практику. Хочу, скажем, IDE-шку получше изучить, библиотеку или язык. Для такого проекта у меня будет только Write в ваших терминах: мне даже критические ошибки в этом коде необязательно исправлять, это просто черновик. Никаких compile, run, bisuness, test, modify тут не будет. Да, write тут станет ценным уровнем, хотя выше я утверждал обратное, но только из-за специальной цели всего действа.
Возьмем прикладную утилитку личного пользования, а то и одноразовую. Ее уже надо собрать, запустить, но test, modify, business не будет. Возьмем инди-игрушку: тесты могут быть, могут нет, зато появляются производительность и бизнес. Построитель отчетов для внутренннего пользователя компании: тесты обязательны, это важная информация, зато производительность может быть выкинута, как и легкая модификация. Фреймворк: тесты, производительность, читаемость, документация, но может не быть business и легкой модификации. Ключевой сервис компании: тесты, легкая модификация, производительность. Открытое ПО - необходим выстроенный и поддерживаемый процесс коллективного принятия решений и внесения изменений; кстати, тут появляется "процесс" помимо продукта и исходника.
Возьмем любой программный компонент: при наличии доступного уже готового софта выкидываем (!) write, compile, даже run в случае стороннего сервиса. Можно утратить исходники и остаться с бережно отныне хранимым бинарником, который будет годами успешно работать, процеденты такие есть. А то и вовсе все сделают другим способом - механикой, электрикой вместо электроники или еще как-то. Задача решается без написания единой строчки кода, почти что идеал; круче только удалением.
Для специальных случаев добавим всякие интересные условия типа работы в масштабе миллиардов пользователей, в realtime, в жестких ограничениях по CPU/RAM/IO или обязательного использования особенностей конкретного железа, без которых все опять-таки не будет иметь никакого смысла.
Легко заметить, что ни один из ваших пунктов не оказался сразу во всех перечисленных сценариях - правда, занятно? Кстати, производительность и читаемость/поддерживаемость обычно являются взаимоисключающими, их вместе не запихнешь. Получается, что универсальной схемы развития идеального программного продукта попросту не существует, есть лишь цели на конкретные случаи со своими функциональными и нефункциональными требованиями к готовому продукту, исходникам и рабочим процессам. Как только все требования легли в основание, можно поверх что-то строить, но не линейное, а очевидно (хехе) многовекторное, больше похожее на розу ветров. А раз уникальное и многовекторное - значит, единой цели не может быть.
P.S. есть интересные эксперименты (например, Вселенная-25), косвенно связанные с пирамидой Маслоу, показывающие-таки наличие ее верхней границы.
эээх. Сам Маслоу никакой пирамиды не рисовал. Он написал, что есть потребности физиологии, которые будучи неудовлетворенными- перебивают вообще все остальные вопросы мотивации. А после удовлетворения этих физиологических потребностей есть целый ряд других потребностей, которые вроде как упорядочены по иерархии, но эта иерархия вообще никак не жесткая, из нее есть исключения и этих исключений- много (http://psychclassics.yorku.ca/Maslow/motivation.htm, Part 3)! А потом уже какие-то ушлые дизайнеры понарисовали красивых пирамид, приплели к этому Маслоу, который сам в шоке от того, чего из него сделали и носятся с этой пирамидой, как с догмой, пихая ее куда надо, и куда не надо.
Вселенная-25 с пирамидой Маслоу связана оооочень косвенно- через потребность в признании у авторов Вселенной-25 :-). Потому как крысы- это животные, как это ни странно- чистоплотные! А вольерчик во Вселенной-25 чистили раз в две недели! то есть, крысам там жестко прищемили базовую потребность в комфорте. И температурка там прямо скажем, была некомфортная- лето было, жара, а ни кондеев, ни обдува не предусмотрено было в экспериментальном ангаре. Кроме того, организация жилых отсеков- звезда звезд, предполагала возможность контроля одной особью целого общежития, то есть, молодые самки физически были лишены возможности доступа к изолированным норкам- на входе на этаж сидела жирная старуха, в результате получилась смешная ситуация- крысам закрыли потребность в еде и напрягли по всем остальным возможным пунктам их не самой простой организации жизни. А вот в популярной литературе расписали это как будто организовали им там рай райский, а они в нем жить не захотели. Им организовали гетто-коммуналку в сортире, совмещенном со столовой на 500 рыл, с жарой и общими корридорами в качестве бонуса (линк на техническое описание эксперимента я щас не найду, но для любознательного читателя комментов, думаю, не потребуется много времени чтобы перепроверить мои слова), там не потолок пирамиды Маслоу достигался, а дно днищенское этой пирамиды.
Маслоу никакой пирамиды не рисовал. Он написал, что есть потребности физиологии, которые будучи неудовлетворенными- перебивают вообще все остальные вопросы мотивации.
Безотносительно к сути вашего комментария, с которой я согласен, внесу незначительное уточнение - Маслоу не писал и то, что все потребности физиологии перебивают всю прочую мотивацию.
Суть идеи там была в том, что некоторые потребности получают повышенный приоритет на разных этапах жизни. И по мере не сиюминутного удовлетворения, но обретения насыщения, то есть уверенности в возможности удовлетворения, человек получает способность легче переносить временную невозможность удовлетворять те или иные потребности. Вплоть до самопожертвования при необходимости совершить подвиг.
Младенцам важнее не страдать от холода и голода, далее ребенок учится справляться со страхами, затем юнцы меряются признанием, подростки добиваются уважения и, по мере взросления, начинают задумываться о смыслах и своем месте в жизни, и при насыщенности во всех предыдущих потребностях обретают силы для этого самовыражения - вот упрощенный пересказ того, что выродилось в "пирамиду сиюминутных приоритетов".
И в схеме Маслоу есть масса исключений, помимо перечисленных самим Маслоу. Например, младенцам критично важна любовь, а в самореализацию пытаются выйти и неблагополучные. Не говоря уже о том, что те же физиологические потребности слишком разные, не входят в группу с единственным приоритетом. Не говоря уже о том, что нет потребности в безопасности - есть потребности в уходе от конкретных известных опасностей. Не говоря уже о том, что существуют десятки потребностей плюс сотни вторичных, которым не нашлось места в "пирамиде", хотя они продолжают работать и иногда получают наивысший приоритет.
Когда в очередном эксперименте (An examination of Maslow's need hierarchy in an organizational setting) в очередной раз развенчали и опровергли идею "пирамиды", Маслоу просто и однозначно ответил - вы не учитывали возраст. А когда Выготский обосновал и подтвердил "Концепцию параллельного мотивирования", у специалистов вопросов уже не оставалось, но "пирамида" отделилась от науки и зажила самостоятельной жизнью в трудах, популяризирующих неведомо что.
И вот на основе пирамиды, не имеющей обоснований, мы видим попытку нарисовать новые пирамиды. По-видимому, со времен древнего Египта, люди видят в пирамидах что-то особенно привлекательное. Люди любят раскладывать разнородное в простые цепочки. А нарисованное основание выглядит самодостаточным обоснованием. Бедный Маслоу.
Думаю, что у каждого своё понимание зачем он программирует. Соседство Run и Business в статье скорее всего говорит об изначально рациональных мотивах автора. Это достойно уважения на самом деле.
Для меня программирование это игра. Как играть на гитаре, например, или в шахматы. На кухне, в парке, в пабе - какая разница? Это не спорт и не бизнес. Критерии оценки результата в первую очередь основаны на внутреннем ощущении удовольствия, красоты и достаточности (здесь я говорю о личных мотивах, а не формальных quality attributes, которые зависят от целей конкретного проекта). На работе я это делаю за деньги, решая бизнес задачи, чтобы кормить свою семью и давать возможность колллегам делать то же самое. Но по большому счету эта суета тут за скобками.
Я, возможно, не понял, что хотел сказать автор, но, на мой взгляд, автор зря делает две вещи:
- Смешивает между собой понятия "цели" в смысле "цели решения задачи, бизнеса, удовлетворения потребности, каковую должен удовлетворить создаваемый программный продукт" и в смысле "цели программиста по приближению технического уровня исполнения программного продукта к уровню гипотетически идеальному". Эти две цели не просто зачастую плохо сочетаются, а то и противоречат друг другу — каждая из них сама многокомпонентна, и компоненты эти, зачастую, сами плохо между собой сочетаются, а то и противоречат друг другу. Цель бизнеса может вполне удовлетворительно для бизнеса решать едва скрипящий MVP, на код которого без слёз не взглянешь. И, напротив, технически отлично исполненный продукт может решать её хуже или вовсе не решать.
- Пытается всю эту сложную мешанину свести в единую пирамиду строгой иерархии — там не будет пирамидальной иерархии, а будет — если будет — что-то вроде диады "инь-ян", только не с двумя элементами, а с парой десятков входящих в противоречия друг с другом элементов, для которых, под каждый случай, надо находить свой уникальный баланс (как в известном примере: "эту задачу можно решить быстро, дёшево и качественно — выберите любые два пункта", только сложнее гораздо).
- Вкорячивает туда пункт "чтоб обязательно за деньги". Совершенно параллельный момент, программирование, за которое не платят, от этого не перестаёт ни существовать, ни быть программированием.
Вотъ. Вот эти вот три пункта испанской инквизиции, на мой взгляд, автор делает совершенно зря.
Цель программирования — создавать ПО, удовлетворяющее потребностям пользователя. Всё остальное — средства достижения этой цели.
Я бы выделил два основных фактора/цели/причины:
1. Бизнес потребности
2. Творчество
Иногда они пересекаются
Всё остальное - средства достижения целей
Хватит искать смысл и цель там, где их нет. Просто пишем код, получаем зарплату.
Конечная цель программирования - получать радость. А иначе зачем это всё? :)
В том, чтобы иметь код, который легко изменять
Идеализация - высшая форма глупости.
У программирования, как у любого другого процесса чисто утилитарные свойства, как у молотка - забивать гвозди. Несомненно есть люди, которые покупают себе очень дорогой молоток, забивают очень специальные гвозди и так, чтобы, тот кто их захочет вырывать - делал это с комфортом.
Но вы в своей практике в 90% случаев сталкиваетесь с тем, что до вас никто так не делал и то что именно вы так будете делать - ровным счётом ничего не изменит, вы просто будете всегда тратить много времени и сил на лишнюю работу.
Поэтому я бы сказал что программирование:
1) Для души
2) Для заработка
Кто-то умеет это совмещать (не я точно), но я только для души пишу и очень давно. Уверен что 90% программистов делают это ради заработка. И какая разница что там потом будет после вас?
Конечная цель/остановка - AGI. )
Задача программиста — намагнитить быстро вращающуюся металлическую пластину в нужных местах. (с) народное творчество
Не вижу смысла углубляться так далеко. Моё мнение - цель лишь в выполнении прикладной задачи, которую поставил программист. Разумеется, задача меняется от проекта к проекту.
А кода без задачи быть не может. Даже если человек просто тренируется, а не пишет что-то определенное, то тогда задачей этого кода будет практика программирования его автора.
Не увидел ту первую статью, когда она вышла, и прочитал только сейчас.
Больше всего места в ней занимает разбор примера реализации требований отображения 3 элементов списка вместо 1. И автор советует не вводить параметр, а просто захардкодить число 3 где-то в коде.
С этим я не согласен. А если завтра скажут — 4?
Где гарантии, что эта тройка в коде встречается ровно 1 раз? Придётся заново вычитывать код, проверять все подозрительные тройки, и соседние с ней числа, например, в конструкциях типа
if (list.Count > 2)
Это повторное выполнение работы, которая уже сделана. Лучше сразу сделать хорошо, выделив эту тройку в параметр. А что касается тестов? Кто заставляет писать их на все варианты параметра, в том числе отрицательные? Пишите на кейс, который сейчас нужен — для n=3. При необходимости, тесты можно потом дописать.
Получилась пирамида для китайской комнаты - нет постановки задачи, нет алгоритма, нет требований. И всё это должно было быть на этапе до написания каких-то символов в какой-то блокнотик.
У вас в рассуждениях фундаментальная ошибка в самом начале. Вы задаётесь вопросом "какая цель?", а в итоге большую часть статьи рассуждаете не о цели, а о средствах её достижения. Цель программирования - программа. А код - это средство достижения цели. К примеру, вот такая программа может полностью удовлетворять всем критериям из вашей пирамиды, но при этом является абсолютно бессмысленной:
if (FALSE) {
// Миллион строк легкоподдерживаемого и удобно-расширяемого кода
}Какова бизнес-задача, решаемая этой программой?
Бизнес-задача может решаться вне блока if. Но при этом внутри недосягаемого блока может быть какая-то сложная логика, задействующая много разных классов, объединённых какими-то паттернами, да ещё и покрытых юнит-тестами. Факт запуска юнит-теста при этом закрывает ярус Run из вашей пирамиды. То есть программа по факту работает, и код в ней крутой, но ненужный.
И кстати есть ещё один очень важный критерий любого кода - ресурсоёмкость. Почему-то об этом очень часто забывают. До недавнего времени было принято считать, что в случае серверных приложений выгоднее нанять более дешёвых разработчиков, но арендовать более дорогой сервер, но в последнее время всё чаще бизнес стал понимать, что выгоднее один раз заплатить программисту условно на 5000$ больше, чтобы в будущем экономить 200$ в месяц на инфраструктуре
Что-то я вас не понимаю. Цели закрываются по иерархии: Write -> Compile -> Run -> Business -> ... Приведённый вами фрагмент кода сваливается уже на уровне Business - он не решает никакой задачи. Все остальные, вышестоящие, цели в иерархии просто теряют смысл.
Вы можете спокойно выкинуть код под if(FALSE) {...}. А можете не выкидывать и так пытаться понять, что я имел в виду под иерархией целей. Но это будет сложнее и тут я вам, пожалуй, не помощник. Я тоже тут теряюсь.
Я привёл этот пример только за тем, чтобы показать, что решение бизнес-задачи - это и есть единственная конечная цель программирования, а все остальные ярусы пирамиды ну никак не могут являться конечными целями ни в каком понимании.
Тем не менее, в вашей пирамиде есть одна интересная закономерность. Под ярусом Business у вас перечислены необходимые технические критерии, а над ярусом - экономические. Ненаписанная, не скомпилированная или не запускаемая программа по определению не может выполнить задачу. А вот плохо читаемая, плохо тестируемая и трудно модифицируемая программа с задачей может справляться хорошо, но быстро станет для бизнеса невыгодной.
Освоить финансирование на написание /bin/true, подтвердив трудоёмкость.
Вполне возможно, что этот блок был полезен, но задачи бизнеса поменялись и, чтоб совсем его не удалять, оставили так. А завтра бизнес может попросить этот блок вернуть.
Вашу мысль правильней изображать не в виде пирамиды, а в виде вложенных одна в другую петель обратной связи, каждая из которых может "вернуть" код на доработку. Написали строчку - увидели что строчка слишком длинная - исправили, увидели что компилятор ругается - исправили, тест не прошел - исправили, зарелизили, всем понравилось - всем захотелось миллион новых фич - исправили и т.д.
Так вот, если вы надеетесь, что ваша программа станет успешной, то нужно быть готовым, что к вам придут просить миллион новых фич, и с большой вероятностью "проблема Возняка с лимитом 2к на размер" из комментов здесь будет наименьшей проблемой из тех, что у вас будут, вам ради новых фич с радостью докинут и 2к места, и 222к если надо будет.
Согласно дяде Мартину (книга Совершенный код), основная задача программирования это **управление сложностью**.
Как реального мира (упрощая взаимодействие с ним и изменение оного), так и собственно программных продуктов
Так в чём же конечная цель программирования?