Software-Development

There’s a widespread belief in software development circles that we should minimize complexity at all costs. It’s treated like a cardinal sin, whispered about in code reviews like some kind of software taboo. “Keep it simple,” they say. “Reduce complexity,” the metrics dashboards scream. But here’s the thing—I’m going to take a stance that might get me some raised eyebrows: complexity isn’t your enemy. Negligence is. Before you close this tab thinking I’ve lost my mind, hear me out....

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

We’ve all been there. It’s 11 PM on a Friday night, your feature works, tests pass, and the code review is pending. But something gnaws at you. That function could be more elegant. That class hierarchy could follow a more sophisticated pattern. That variable name could be even more descriptive. You refactor. You restructure. You rename. And suddenly, what should have shipped three hours ago is still sitting in your local branch, shiny and perfect, while your colleagues have gone home....

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

Look, I’m going to say something that might get me uninvited from the next Agile conference: user stories aren’t always the answer. There, I said it. Before you close this tab and write an angry comment about how I “don’t understand Agile,” hear me out. I’ve spent years watching teams religiously convert every single requirement into the sacred “As a… I want… So that…” format, even when it made absolutely no sense to do so....