С другой стороны, чрезмерное упрощение приводит к тому, что код пухнет на глазах, и становится плохо поддерживаем. У меня есть теория, что существует 2 типа программистов. Программисты с условно "большой оперативной памятью", которые легко работают с функциями длиной 500 строк, помнят про 300 глобальных переменных и то, где какие файлы лежат. Такие люди очень хорошо делают quick and dirty код и могут запустить техническую часть стартапа за неделю. А есть люди, у которых встроенный графовый процессор. Такие люди очень плохо работают с функциями в 500 строк, но могут держать в голове систему из множества взаимодействующих компонентов. Эти люди могут расчистить авгиевы конюшни исторических наслоений легаси и написать рядом систему, которая уже будет использовать кубернетес, кафку и прочие модные технологии к месту. Проблемы начинаются тогда, когда вторые люди приходят в стартап и начинают строить кубернетес кластер, либо когда люди первого типа приходят на проект с большой сложной системой, и начинают поверх нее строить хаки для быстрого запуска. К тому же эти два типа людей часто ненавидят друг друга :) Так что с моей точки зрения существует не только проблема оверинжениринга, но и проблема излишнего упрощения, которая скрывает сложность системы хардкодом и дублированием. Как всегда, нужен баланс, а скатывание в крайности понижает эффективность работы. Не важно будет ли это оверинжиниринг или чрезмерное упрощение.

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

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

сорри, я чет никак не могу вкурить) что “это” выглядит и какой одной и той же проблемы?

https://t.me/ctodaily/1233

Спасибо, @samatg за пост!

Кажется, ссылку на Бакунова отправлял я, потому утверджение про советские газеты и использование головы принял как личное обращение. :)

Что у нас есть на текущий момент.

Кроме [обработки исключения](https://github.com/signalapp/Signal-Android/commit/c95f0fce6ee3b78ff82fde865b2ee49288e1303f#diff-160146dbaa14fdad2763ce9cbc0495fa58af07625b6a6e102c5c419fb8103693R130) ServerRejectedException (не повторять запрос, если сервер сказал, что ему тяжело) во множестве участков кода, после падения также было добавлено:

- Возможность [контроля максимального back-off](https://github.com/signalapp/Signal-Android/commit/93e9dd6425b22db13baaf7e7f780a93bda0a457e#diff-d10b2f5f1993c59be87d4bb45d89dcf84eade9b88777286f3beac1ec81282cd1R71) интервала с сервера. Раньше это было [30 секунд!](https://github.com/signalapp/Signal-Android/commit/93e9dd6425b22db13baaf7e7f780a93bda0a457e#diff-bd141820aea6050a28f07d92c3a8008fc18a810202c5e5c65968487ea979c5b3L343) (и 2 часа для сценария регистрации).

- Возможность удалённо отключать [автоматический повтор запросов](https://github.com/signalapp/Signal-Android/commit/05149503333e94bf5ac958f35ea3cacc4a093bd9#diff-d10b2f5f1993c59be87d4bb45d89dcf84eade9b88777286f3beac1ec81282cd1R101).

- Исправление того, что некоторые сетевые задачи [не использовали общую очередь](https://github.com/signalapp/Signal-Android/commit/3e43963f674b2e735ae060ecf0739881aeb4acbe#diff-71b63432150fdbdbbc56620a00ef07afecbcf0148f3af6c333e1951b8efe3a92R46).

Кроме того:

- [сторонний разработчик](https://github.com/signalapp/Signal-Android/commit/c95f0fce6ee3b78ff82fde865b2ee49288e1303f#r46037577) пишет, что у него в логах полно 503их ошибок, которые клиент обработает как таковые, что вынуждают повторять запрос.

- В июле аудитория Signal была около 30 миллионов человек. Сколько из них пользовались мессенджером активно (при наличии других более удобных альтернатив) - это вопрос. Например, очень-очень давно я поставил Signal просто посмотреть и удалил. Попадаю ли я (и пользователи их этой когорты) в эти 30 млн? Подозреваю, что да. Когда пошла недавняя шумиха, я тоже поставил Signal абы посмотреть что у них изменилось (и из стадного инстинкта, конечно же). Есть ли ещё люди, которые повели себя так же? Вероятно.

- В декабре количество регистраций в Signal пробило 50 млн. Я не смог найти статистику по устройствах, но огромный прирост в Индии почти наверняка значит бешеный прирост Android-аудитории (уже сейчас Google Play показывает 50+ млн установок).

- После бума Signal в спешном порядке увеличил количество серверов, посколько к таким нагрузкам (и такой популярности) они, похоже, готовы не были.


Итого, ждём отчёта об инциденте, но отсутствие новостей от самой компании, огромный и неожиданный для бизнеса прирост аудитории, характер и количество изменений в коде Android-клиента - все это позволяет предполагать, что гипотеза об упавших серверах, которые не смогли отбиться от лавины (повторяющихся каждых 30 секунд с миллионов устройств) запросов, кажется довольно вероятной на данный момент.

претензия была не к тебе совсем! это я завидую популярности addmeto. Ну и реально не думаю, что все легло из-за одного андроида. Наверняка были ботлнеки, которые помешали горизонтальному масштабированию и я считаю, что root cause именно в этом, а не в том, что сервис стал популярнее.

Кстати, @classmethod, ты сказал, что "Simplicity/complexity это измеряемые понятия. Можно подсчитать в любой единице измерения сложность разработки, тестирования, внедрения, поддержки, сопровождения.". Нет ли у тебя случайно какого-нибудь толкового (и не очень длинного) флоу по анализу ДО того, как какое-либо решение было фактически имплементировано?