I'm a developer of the younger generation (29 y.o., 9 y. exp.), and this article strongly resonated with me. I've been struggling to grasp for years what exactly it is about "Agile" that I find so endlessly frustrating.

If I were to work on a hobby project, I'd be able to create a proper roadmap, hold the complete idea of the product in my head, and then create the proper abstractions.

But, at every software engineering job I've had, I'm saddled with delivering one eerily similar feature after another, completely blind to what the "plan" is beyond the next two-week "sprint," and watching the codebase quickly deteriorate. Then, as project managers continue to churn out more and more user stories with highly similar features, they just distribute the tasks to more developers on the team, leaving each of them to just go their own way and reimplement the same thing repeatedly in subtly different ways. Any time a developer does go above and beyond, trying to create a reusable abstraction around some common business logic, he's the only one who uses it. Why risk trying to interface with some other developer's black box module? "It's easier to just write my own..."

Soon enough, somebody adds some new user permission to the system and there are a dozen or more scattered snippets of code with bugs, each with totally independent implementations of what is practically identical logic.

No amount of meetings (of which no productive engineer can even pay adequate attention to and also get work done) can solve the problem of condensing the software development process into two-week iterations. All it does is inform management, incorrectly, that we will build more things faster if they throw more people at it.

I'd rather have a small group of engineers, each of whom is responsible for a suite of related features, or responsible for a specific part of the system, than a "team" of engineers.

P.S. Pairing is the absolute worst, and I will avoid it at any cost!