Про ёжика в тумане, зазнайство, языки программирования и вериги

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

Как кудесники монад и эндофункторов объясняют нормальным людям работу их софта? «Иди читай код, болван!» работает только на программистах. Да и то, только на тех, которые не умеют правильно посылать.

Устаревшие методы позовляют нормально коммуницировать если не с обитателями отдела маркетинга, то с людьми, способными думать.

- Идентификатор заказа состоит из полей Число, Время, Источник Запроса, Путь Получения и Уникальный Номер. Для таблицы мы группируем записи по времени с интервалом час и подсчитываем среднее для Пути Получения.

- Менеджер Задач ожидает прихода сигналов. Если сигнал А приходит раньше Б, выполнение продолжается. Если Б не приходит в течении заданного промежутка времени, ситсема снова посылает запрос. Если Б приходит раньше А, Менеджер Задач выдаёт ошибку и переходит в состояние ожидания перезапуска.

- Когда пользователь нажимает на кнопку, окно получает фокус ввода и меняет цвет на синий.
...

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

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

Чтобы не усложнять задачу, представим, что мы руководим группой Очень Крутых функциональных программистов, которые сделали Крутую Программу. Теперь мы сидим в переговорной комнате вместе с заказчиками и пытаемся всеми доступными средствами объяснить, что же такое замечательное они от нас получат. При этом, заказчики должны во-первых, понять, а во-вторых, заметить те мелочи, которые не соответствуют требованиям и особенностям конкретного применения.

Moneyfall taming and other lost secrets of ancient ages

По просьбам трудящихся...

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

---

Please do not mistake Agile for agile. The Agile processes that declare as their main goal to show "something" to stakeholders and then squeeze from them money in endless feature adding cycles are not the agile processes that have short error correction cycles (including budget corrections, process planning corrections and corrections of user expectations).

You cannot mount windows in a palace and after that replace inside water closets with dining rooms. But this is an easy task, if your building reminds an anthill.

If you read old software engineering literature prior the rise of Right Methods (before 90s), you find the "old true" agile that had that time other names and was not a silver bullet but a set of ordinary and obvious principles. (Including principles of the real life application for the "evil" Waterfall Model.)

And note, the "old" agile means the correction of any kind of errors from any kind of sources. If you have The Priests of The Sacred Agile who are always right, you are not agile. You worship an evil cult.

(Vit-R)

---

Надо, конечно, сочинять такое коллективом с участием носителей языка с рождения. Но молодое динамичное поколение это обзовёт творчеством коллектива неудачников.