Размышления о судоку, или невозможность систематизации мысли ( rjp.io )
Это было интересное чтение, но исходная статья просто захватывающая https://explaining.software/archive/the-sudoku-affair/
TDD как инкрементальный поиск от простой начальной точки к решениям. В этих терминах это будет работать, когда путь от начала до решения будет плавно дифференцируемым.
Я был очарован “Делой Судоку”, обнаружил, что размышляю о внутреннем мышлении сторонников TDD, и пришел к неудовлетворительному выводу, что невозможно систематизировать мысль. Не лучшее мое сочинение, но я все равно подумал, что поделюсь.
Я думаю, что в идиотской мечте об управлении есть аналогия: существует процесс, с помощью которого можно заменить этих дорогих квалифицированных рабочих дешевыми неквалифицированными идиотами и все равно получить отличные результаты.
Еще один вариант: волшебный процесс, позволяющий добиться отличных результатов от людей, которым все равно.
Совершенство не приходит только из процесса. Показатели отличного процесса с неквалифицированными рабочими, которым все равно, — это фастфуд, а этот продукт неизменно посредственный. Постоянство — это хорошо, но постоянная посредственность — это недостойная амбиция во многих областях.
НАСА в значительной степени ориентировано на процессы, но они доставляют людей в космос и обратно, и люди, участвующие в их процессе, обладают высокой квалификацией и глубокой заботой.
Ларри Уолл, изобретатель Perl, говорил (и, вероятно, говорит до сих пор), что сложность должна куда-то деться. Если вы решаете сложную проблему, то это либо простая программа со сложными инструментами, либо сложная программа с простыми инструментами.
Это действительно застряло во мне. Искусство проектирования библиотек, фреймворков, языков, API заключается в предоставлении набора инструментов — если вы делаете простые инструменты, то сложные проблемы становятся сложными программами. А если вы предлагаете сложные инструменты, то сложные проблемы могут иметь простые решения. И люди будут ворчать на вас за всю пунктуацию десятилетиями. 🙂
Но сложность существует и от нее нельзя отмахнуться. Что, в общем-то, тоже относится к вашей точке зрения. Спасибо, что написали!
> Последовательность хороша, но постоянная посредственность — недостойное занятие во многих областях.
Извините, что беру лишь малую часть отличного комментария, но так ли это на самом деле? Мне кажется, что есть множество областей, в которых последовательность важнее совершенства, особенно если стремление к совершенству иногда приводит к большим промахам. В хорошо спроектированной системе с некоторым допустимым допуском, пока она достаточно хороша, все в порядке. Возьмем, к примеру, электросеть: нет никаких призов за поддержание частоты в пределах наногерца от спецификации. Существуют очень большие штрафы за выход за пределы спецификации (+/-0,050 Гц для сети ЕС). Быть постоянно в пределах спецификации гораздо ценнее, чем иногда работать намного лучше спецификации.
Только в экстремальных областях, где победитель получает все, таких как спорт, космонавтика и предпринимательство, быть абсолютным лучшим — это то, чего вы хотите. В большинстве других областей быть постоянно порядочным лучше, чем переменчивое превосходство. Я бы определенно не хотел, чтобы мой стоматолог предпринял рискованную попытку достичь совершенства, например.
«Я бы определенно не хотел, чтобы мой стоматолог предпринял рискованную попытку достичь совершенства». Отличный комментарий.
Я осознавал, когда писал это, что последовательная посредственность действительно является прибыльной целью. Возможно, мы придираемся к “посредственности”? Оставаться в пределах спецификации кажется достаточно сложной задачей для сетки, я не уверен, что я бы определил совершенство как все более и более узкую вариацию вокруг спецификации там.
Я выносил моральное суждение в «недостойном». Мне нравится, когда машины сходят с завода стабильно хорошими. У меня есть Tesla, это утверждение для меня очень важно. Это кажется вызовом. Я бы не уважал завод Lada за то, что он постоянно выпускает автомобили, которые ломаются или разваливаются, так же как я не уважаю McDonalds за то, что он постоянно поставляет невыразительную еду. Я признаю стабильность, я признаю, что это прибыльно, но они не достигают стабильного величия.
> есть процесс, с помощью которого можно заменить этих дорогих квалифицированных рабочих дешевыми неквалифицированными идиотами и все равно получить отличные результаты. > Другой вариант: волшебный процесс, который позволяет вам получать отличные результаты от людей, которым все равно.
Разве не это в значительной степени то, что делают американские военные? Они принимают “тупых” подростков + документы + процессы и получают из этого все, что им нужно? Это также дешево (по сравнению с промышленностью). И к концу учений “тупые” подростки становятся специалистами в своей собственной нише, некоторые из них – высококвалифицированными (см. ядерные специалисты, диспетчеры, пилоты, штурманы, менеджеры, закупщики и т. д.)
Военные процессы лежат в основе многих организационных подходов, которые мы применяем в разработке программного обеспечения и бизнесе (agile, scrum, ooda и т. д.)
Откуда вы взяли, что это дешево? Военные известны тем, что они невероятно тратят деньги. Им нужны невероятно специфические навыки, которым на самом деле не учат в гражданском мире. Это означает, что военным нужно обучать всех за свой счет. Так что, хотя на входе могут быть «дешевые, неквалифицированные идиоты», затем есть значительные расходы, чтобы превратить их в дорогих квалифицированных неидиотов, прежде чем они будут готовы к службе.
Честно говоря, как человек, проработавший в армии 14 лет, я с большой натяжкой могу сказать, что они постоянно добиваются «отличных» результатов.
Мне кажется, вы говорите, что образование (как оно практикуется в армии США) — это довольно надежный процесс, позволяющий взять неквалифицированных людей и сделать из них квалифицированных. Я согласен.
В армии США есть критерии приема. Они выгоняют людей с базовой подготовки и со всех остальных частей обучения. Не всем достается должность диспетчера, пилота или специалиста по ядерной технике. Управление воздушным движением, как оказалось, не тот процесс, в который можно поместить неквалифицированного человека. Он требует обучения и тщательной интеграции, и как только у вас появится квалифицированный человек, вложивший в него много часов, возможно, вы сможете позволить ему управлять движением.
Обучение — это не волшебный процесс, который берет неквалифицированных людей, которым все равно, и каждый раз дает отличные результаты. Эквивалентом в нашем мире было бы: «Я найму дешевых людей, которые не умеют программировать, проведу их через процесс Bootcamp, и тогда у меня будут отличные программисты». Это не сработало.
Я пытаюсь сказать, что: каждая версия программирования, где был Процесс, которому вы просто должны следовать (из Jackson Structured Design), потерпела существенный провал и не стала заменой найма умных людей, которым не все равно. Если бы кто-то пришел ко мне с бизнес-планом, который звучал бы как «наймите посредственных людей, которым все равно, и мы достигнем отличных результатов благодаря Моему Процессу», я бы был ооочень скептичен.
> Военные процессы лежат в основе многих организационных моментов, которые мы применяем в разработке программного обеспечения и бизнесе (agile, scrum […])
Agile Manifesto был как раз контрманифестом этому, и поэтому любая методология, называющая себя гибкой (например, Scrum), является:
Agile-манифест
Принципы, лежащие в основе Agile-манифеста
> https://agilemanifesto.org/principles.html
Хотя “Scrum” на самом деле не “Agile”. Может быть, кто-то разработал его с помощью действительно Agile-процесса, но затем заморозил его и выставил как неизменный идеал, и пошел по такому привлекательному пути, говоря всем, кто считает, что это не работает для них, что это потому, что они делали это неправильно.
Я обнаружил, что мне приходится проводить большую разницу между тем, что я называю «настоящим Agile» и Scrum, потому что Scrum — это именно то, против чего и возник настоящий Agile.
Я использовал Scrum в поисках идей для своих гибких процессов, но я никогда не буду делать это строго в точности.
> Хотя «Scrum» на самом деле не «Agile».
Википедия:
> https://en.wikipedia.org/wiki/Scrum_(разработка_программного_обеспечения)
«Scrum — это гибкая структура совместной работы команды, широко используемая в разработке программного обеспечения и других отраслях».
Другими словами: люди, которые утверждают, что применяют Scrum, но не используют Agile, — просто мошенники.
Разве нет менее концептуальной (но все же концептуальной) проблемы, что правильность программного обеспечения обычно является резкой, а не непрерывной? Вы не получаете ряд почти правильных программ, постепенно приближающихся к правильной программе, у вас есть правильная программа, а ее вариации могут полностью не сработать.
Конечно, буквальность этого утверждения зависит от того, к какому типу алгоритмической задачи вы приближаетесь.
Но должно быть много реальных проблем, в которых очень-почти правильная программа производит совершенно неправильное поведение, которое вообще не похоже на правильное поведение. В таких обстоятельствах вы не могли бы ожидать, что найдете правильную программу эмпирически через итеративные улучшения.
Редактировать: Возможно, подход на основе инкрементного тестирования будет работать в случаях, когда у вас есть заданная извне спецификация или проект, который уже разбивает алгоритмическую часть на более мелкие, простые и более проверяемые части.
Я всегда использую следующую аналогию:
Если ваш клиент заказывает функцию, вы реализуете весь код, отсутствует только кнопка для вызова функции, то вы ничего не предоставляете.
Если вы просто добавляете кнопку в программу, но не реализуете ничего больше, вы предоставляете функцию. Она просто все еще глючит.
> Разве нет менее концептуальной (но все же концептуальной) проблемы, что правильность программного обеспечения обычно является резкой, а не непрерывной? Вы не получаете ряд почти правильных программ, постепенно приближающихся к правильной программе, у вас есть правильная программа, а ее вариации могут полностью не сработать.
Я считаю правдоподобным, что такая топология может существовать (по крайней мере, для многих ситуаций). Проблема скорее в том, что такая топология, скорее всего, будет вести себя совсем не так, как ожидают пользователи.
Да. Разница между “Программа, которая делает то, что вам нужно” и “Программа, которая вылетает при запуске” может быть в один символ.
Ого, статьи Рона Джеффриса немного смущают, а он даже не понимает. Вот почему догма никогда не работает.
Source: news.ycombinator.com