Рубрика «воображаемые проблемы»

Проблемы накапливаются. Софт тормозит. Везде некомпетентность и хаос - 1

Закон Старджона гласит: «Ничто не может всегда идти правильно». Рано или поздно всё ломается.

Это естественная причина, почему софт ухудшается с каждым годом. Иначе и быть не могло. Кодовая база растёт, количество ошибок увеличивается, проекты просто тонут в багах.

Взять недавний случай с багом в Windows Defender, который вызывал тормоза Windows. Крайне показательная история. Да, этот баг обнаружили, но в кодовой базе остались такие же. Мы этого не знаем наверняка, но вполне логично предположить, что количество скрытых багов растёт пропорционально кодовой базе. Поэтому софт всё больше тормозит со временем. Это естественный процесс, почти как закон природы.Читать полностью »

То, что их интересно решать, не означает, что они кому-то нужны

Мнимые проблемы — причина плохого софта - 1
«Группа людей проводит мозговой штурм над ноутбуком и листом бумаги», фото Стефана Стефанчика с Unspalsh

Есть много факторов, которые приводят к созданию плохого ПО: выбор инструментов, общение в команде, личная незаинтересованность разработчиков в успехе, методология тестирования. Мне кажется, у всего этого есть главная первопричина: это воображаемые проблемы.

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

Или делайте это правильно


Если выбрать одну идею, которая убивает больше всего продуктов, то это создание запаса на будущее (future proofing).

Обычно идея проявляется по схеме.

Нам нужен {X}, и хотя сделать {Y} гораздо легче, но при наступлении {Z} первый вариант упростит нам жизнь.

Где {Z} — событие, которое может произойти в далёком будущем.

Вот несколько примеров:

  • Для инфраструктуры нужны Kubernetes и Docker, хотя один большой сервер гораздо проще, но когда придётся масштабироваться до 11-ти серверов, это упростит нам жизнь.
  • Для обработки данных нужен распределённый дизайн, хотя централизованное решение гораздо проще, но когда клиент потребует 99,999% безотказной работы в SLA, это упростит нам жизнь.
  • Нужно набрать команду разработчиков и создать собственное программное обеспечение, хотя WordPress и Shopify гораздо проще, но когда клиентская база вырастет в 100 раз, это упростит нам жизнь.
  • Нужно использовать дизайн на основе наследования типов, хотя композиция гораздо проще, но после 5 лет увеличения кодовой базы это упростит нам жизнь.
  • Нужно написать код в C++ с кэшированием представлений, хотя Python-скрипт с прямыми запросами к Postgres гораздо проще, но при большом увеличении объёма данных это упростит нам жизнь.

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js