Kent Beck is plenty successful - he founded the XP movement back in the late 90s, popularized unit tests, was one of the original signatories of the Agile Manifesto, and wrote JUnit.
If you haven't heard of him, that's a pretty good illustration of his point: success can be fleeting. You can be the foremost programming guru one moment (which Kent Beck was, given my recollection of the late 90s and early 00s) and then fall into obscurity and be just another engineer afterwards.
I think people forget everything they hated before TDD, Agile, XP, etc. Namely the endless parade of bugs, management making unrealistic promises, perpetual crunch time, death marches with no end in sight, code fiefdoms where touching any other engineers' code was basically impossible.
Software is hard. It is getting marginally easier with time, but it still is a lot harder than most peoples' expectations of what it should be. Hence most developers end up disillusioned, frustrated, and unhappy, but this is a product of our expectations more than our processes. A job isn't supposed to make you happy, it's supposed to make your customers happy.
He is responsible for the software engineering evolution from a model that was good for building static stuff like houses and bridges to a model that works well with dynamic stuff with continuously evolving requirements.
Why do you hate TDD, agile and pair programming and what software designing methodology are you following?
At the risk of outing myself, it's a strange correspondence based approach. The idea is that we never commit to a repository but instead email changes to each other, making a patch queue. This has the benefit of forcing every commit to be code reviewed. The process is that we get an email to start work on some new ticket, which will be a reply from the "tip" email that we are supposed to base our work on, with a new subject. This is a development branch, so to speak. We have separate email addresses for separate projects, so project management is fairly hands-off. Requirements are hashed out in these email chains. This has the benefit of making all of our code "literate" in that it is adjacent the requirements.
https://en.wikipedia.org/wiki/Kent_Beck
If you haven't heard of him, that's a pretty good illustration of his point: success can be fleeting. You can be the foremost programming guru one moment (which Kent Beck was, given my recollection of the late 90s and early 00s) and then fall into obscurity and be just another engineer afterwards.