Софт сводит людей с ума

Я как раз собирался написать эту мысль в свежем посте на главной HN «Мы переходим с технологии/архитектуры X на Y», но теперь чувствую, что ей место здесь.

Недавно я болтал с другом о том, как раньше мы делали гораздо больше с гораздо меньшим числом разработчиков: 20 лет назад мы разрабатывали критически важное программное обеспечение реального времени (торговые системы) на C++ командой из пары десятков разработчиков. Команда ядра торгового ядра состояла из четырёх человек. Внутренний инструмент распределённой оркестрации процессов (и фронтенд, и бэкенд написаны на C++) делали два парня. Я сам однажды умудрился создать целую систему управления постторговыми рисками для фьючерсных контрактов за пару месяцев, работая в одиночку. Сегодня я вижу команды по 60–80 человек, работающих над веб- и мобильными приложениями, где подавляющее большинство операций — это CRUD, с некоторой сложностью транзакций/очередей на периферии.

Думаю, разница в технологической текучке. Тогда те немногие зависимости, что у нас были — будь то библиотеки времени выполнения или инструменты времени разработки, — были стабильны: стандартная библиотека, компилятор, unix-команды и bash-скрипты, и некоторые внутренние библиотеки. Большая часть нашего времени и внимания уходила на поиск правильных алгоритмов и структур данных, а кодирование шло вторым. Очень мало времени тратилось на выбор, настройку, обновление, перепроектирование или замену технологических стеков и инструментов.

Автор поста практически наблюдал эффект Эго через программное обеспечение, но ещё не совсем дошёл до способности его количественно оценить.

Перечитайте всё заново и примените каждый приведённый пример через эту призму.

Возможно, мы находимся в отрасли, которая непомерно выражает эту часть человеческой природы, но я почти уверен, что она проявляется везде, хотя и через разные анекдоты. Примените редукционистский дзен-буддийский взгляд к своей профессиональной креативности — и всё это исчезнет.

Боб хочет провести рефакторинг подсистемы, потому что это сделает его героем, и если он правильно подаст это руководству, техническая ценность и фактически достигнутый уровень успеха будут неважны. Алиса решает озвучить некоторые очевидные опасения, а затем откинуться и наблюдать за шоу. Джейн решает всплеснуть руками на стендапе и попытаться эмоционально убедить всех, что небо упадёт. Будьте как Алиса и сохраните рассудок.

Моё наблюдение просто в том, что технические лидеры ошибочно принимают награды от рынка за покорение какой-то абстрактной репрезентации грани домена за покорение самого домена. Затем они становятся манией величия.

Вы покорили коммерческую недвижимость, открыв будущее работы и общества, или построили удобное приложение для планирования?

У вас была классная идея для онлайн-сообщества или вы произвели революцию в человеческих связях?

Напоминает мне этот пост 2014 года «Programming Sucks» [0], который затрагивает некоторые похожие проблемы отрыва от реальности в микрокосме, который всегда «должен» быть лучше, чем есть.

> Все команды программистов созданы сумасшедшими людьми и состоят из сумасшедших людей [...]

> Разрушительное воздействие на мозг демонстрируется языками программирования, которые пишут люди. [...]

> Все программисты заставляют свои мозги делать то, для чего мозги никогда не предназначались, в ситуации, которую они никогда не смогут улучшить, по десять-пятнадцать часов в день, пять-семь дней в неделю, и каждый из них медленно сходит с ума.

[0] https://www.stilldrinking.org/programming-sucks

Это программное обеспечение оказывает такое воздействие или управление продуктами ПО? Я не вижу, чтобы многие академические или любительские программные проекты постоянно меняли то, что для них важно, по прихоти. Хотя в индустрии ПО это видно постоянно.

Дело не в программном обеспечении; дело в том, что большинство менеджеров/администраторов не являются разработчиками ПО (хотя у них могут быть некоторые способности к программированию). Так что они находятся в том же отношении к своей команде разработчиков, как клиенты, жалующиеся производителю на функции физического продукта и говорящие «это должно делать то или это, это легко изменить» (потому что легко представить, что оно у тебя есть, если пропустить нудную часть реализации).

Конечно, иногда запрос оправдан и касается какого-то недостатка исходной спецификации — либо из-за недостатка амбиций, либо из-за избытка амбиций, которые прицепили грузовой контейнер к двигателю газонокосилки. Но большая часть конфликта, описанного в статье, проистекает из сочетания воображения выгод изменения с невысказанным предположением, что реализация — это просто вопрос нажатия ещё нескольких кнопок.

Обожаю эту формулировку. У меня много идей, почему это так, но лучшее (по моему мнению) простое объяснение, которое я смог придумать, такое:

1. Значительная часть создания программного обеспечения — это своего рода математика. В математике вы пишете доказательства, которые объясняют, почему X истинно. В программном обеспечении вы пишете код, который гарантирует, что X будет истинным (например, «бэкенд предполагал, что идентификатор пользователя всегда доступен, но теперь, когда у нас есть сервисные аккаунты, нам нужно изменить код контроля доступа, чтобы всё равно возвращалось разумное представление»)

2. Математика сложна, и большая часть работы — это невидимое мышление. Если бы вы попросили математика оценить, когда будет доказана гипотеза Римана, он бы рассмеялся вам в лицо. Наши задачи в целом проще, но они всё ещё могут быть трудными. И, как в математике, иногда они оказываются гораздо сложнее, чем вы ожидали (например, Великая теорема Ферма. «Почему это было так сложно? Ты разговаривал с Ферма? Он ушёл? Но он сказал, что это будет легко!»)