If there's one thing that all software development experts agree on, it's that the other experts are not always right. There are so many points of view in our industry, it makes the Rocky Mountains look like a tennis court.
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…)
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 RUPcannot 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…