Pragmatism

We love to talk about technical debt. It’s the monster under our bed, the thing we blame for slow sprints and frustrated developers. “We need to refactor,” we cry. “The codebase is a mess!” we protest in retrospectives. But here’s the uncomfortable truth that nobody at your last architecture meeting wanted to hear: sometimes the real culprit isn’t the quick fixes and shortcuts. Sometimes it’s the opposite—it’s the thing we built that’s too damn good for what it actually needed to do....

Мы любим говорить о техническом долге. Это монстр под нашей кроватью, виновник медленных спринтов и разочарованных разработчиков. «Нам нужно провести рефакторинг», — кричим мы. «Базовое кодовое хранилище — беспорядок!» — протестуем мы на ретроспективах. Но вот неудобная правда, которую никто на вашем последнем совещании по архитектуре не хотел услышать: иногда настоящий виновник — это не быстрые исправления и короткие пути. Иногда всё наоборот — мы создали нечто слишком хорошее для того, что на самом деле нужно было сделать....

Every week, without fail, a new framework lands on Hacker News. Every month, a “revolutionary” architecture pattern emerges from a tech conference. Every quarter, some startup with $50M in funding tells us that the way we’ve been building software for the last decade is now categorically wrong. And you know what? They’re probably not wrong. They’re just… incomplete. Here’s the thing nobody wants to hear at tech conferences: the best tool for your problem might be the one you already know how to use....

There’s a particular species of developer I see at conferences, speaking with absolute certainty about the One True Way to structure code. They cite Gang of Four like scripture, arrange their architecture with the precision of a Swiss watchmaker, and look at your pragmatic if-else statement like you just asked them to debug COBOL in the 1980s. They’re not wrong, exactly. They’ve just forgotten something crucial: design patterns are tools, not commandments....

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