A Theory of Everything for Software Development
For example, there's the discussion of agile vs. lean. Some people think they are the same, and others think they are not. Likewise, there's a never-ending debate on agile vs. CMMI. Some experts see a fundamental divide between these two worlds, while others think they are easily bridged. And let's not touch the dangerous subjects of whether or not the Rational Unified Process is agile, and whether or not Prince2 sucks like a black hole. (OK, maybe only three people and twenty big paper manufacturers disagree with that last one, but I digress...)
Einstein's general relativity has proven to be a very accurate description of the universe. Strangely enough, the same applies to quantum mechanics. These two theories are inconsistent. They cannot be joined, because they are only true within their own context. They cannot both be true at the same time and place. That's why theoretical physicists are still looking for a Theory of Everything. (And there's even disagreement in that area, as some scientists think such a grand theory is impossible, while others think it is getting closer every day.)
A little more down to earth, we see something similar going on with Unix vs. Windows. As Joel Spolsky has already pointed out, Unix and Windows are both proper solutions, though each in its own limited cultural context. And they cannot both be the best solution at the same time and place. (And might I suggest that, in the case of operating systems, a Theory of Everything has already been found with the invention of virtual machines? Just a wild thought.)
So, given the circumstances, it appears that... everybody is right!
Agile, Lean, CMMI, RUP, Six Sigma, SWEBOK, Theory of Constraints... each model, framework, method, philosophy and strategy is correct, within its own context. They all have pieces of the puzzle. (And I think some of them even have many pieces.) But none of them seem to be complete. There's always someone saying, "Yes... that's all nice and shiny, but it doesn't work for my unique situation... My context is different." And he would probably be right!
And that's what bothers me.
I've always been interested in the bigger picture. I never cared about any specific methodology. I care about all methodologies, and how they differ from each other. I don't care about any particular software engineering book. I want to read all of the best books available. I have no preference for requirements, design, construction, testing, or any of the many disciplines in our field. What's keeping me awake at night is that the CMMI, SWEBOK and the RUP cannot even agree on what those disciplines are! (And my spouse is having a hard time understanding my tossing and turning all night.)
My aim has always been to understand the big picture for software development. Many thousands of experts have already spent years describing the details of one context-dependent solution after the other. And, even though I'm very interested to know that throwing a ball around can improve my daily stand-up meetings, what I really want to know is how to expand my context. How to broaden my mind to understand how all solutions can fit together nicely in one big model.
I want a Theory of Everything for Software Development
Having such a theory available as a manager, it would be much easier to understand when to apply which solution under which circumstances. It might be able to show me how daily stand-up meetings relate to the PDCA cycle, and whether or not Real Options connects to Critical Chain in some way or another.
And most important of all: where to begin learning...
This blog documents my journey to find that theory.
And I attempt to entertain you with stunning insights and embarrassing nonsense while I'm traveling...
Want to come along with me?
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)