Kent Beck's 3X

I have recently been invited and attended to a talk by Kent Beck hold in Facebook's London Offices.

Before attending the event I (like probably many others) had this mental representation of Kent Beck as a mythological programmer, co-founder of the Agile movement, XP guru, TDD champion, etc.etc.

After the event, I see him more "human" and less "mythological figure", but nonetheless my opinion of him is higher than ever.

First of all, being a so high-profile speaker I believe he has thousands of speeches under his belt, and this translates in a terrific ability to entertain his public: this was a wonderful example of great public speaking, resulting in probably the best tech talk I have ever seen, with the right proportions of jokes and serious informative content.

Apart of being inspired by his charisma, I was also touched by the content of his speech, because he spoke about something that has been troubling me for a while.

I like writing well-crafted code, as readable and well designed as I can get it, with nice tests, etc. etc: we all know that this is not possible in all the situations, because of time constraints, because the code is a throwaway solution, or for some other reason.

This can be frustrating if you always aim for the highest standards, but Kent Beck’s talk enlightened me on this. Like many brilliant intuitions, it has always been obvious and under my eyes, but until someone points this out to you, you just don’t fully get it.

I will not describe the 3X in detail, if you want the details you should really watch the video (this is not the talk I attended, but as far as I can see it is very very similar).

My main takeaway from this is that there is an underlying framework to classify software engineering work.
You are expected to deliver value to your company in 3 different phases/shapes/fashions, the 3X: eXplore, eXpand, eXtract.
Every phase is different, there is not an absolute way of "doing it better" that applies to every phase, on the contrary you are supposed to act differently in different phases, what is good in one phase is very bad in another and viceversa.

This leave us with two options, I guess. We can become generalists and try to apply the best specific practices for every different phase, or we can become specialists in the one phase we like the most, and specialize in its specific best practices... but in the end, despite this decision looks pretty important to me in shaping the course of one own career, how many engineers are aware of the existence of these two different paths?