A Theory of Everything for Software Development

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…)

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?

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
List of All My Articles
Top Five Reasons Why Prince2 Sucks
What is a Project?

Related Posts
free book
“How to Change the World”
  • Rich McCabe

    I think the problem here is that software development is not just about software development–so to speak. A software development project is a human social system, which is possibly not the most complex system there is but darn close. These social systems go through qualitative change when various factors hit a threshold. Like water becoming a solid, or a vapor when certain pressure and temperature thresholds are reached; only in a human social system, it’s the interplay of many, many factors.
    On a software project, we can get an agile team dynamic with about 10 or fewer people. More than that, we have to break it up in to agile subteams, and try to get the team of teams to have that same agile dynamic. Disperse the teams geographically, pull them out of multiple organizations, have them set to be potential competitors in other situations, factionalize the customer, add hardware development as well, bloat the product and the team to be thousands of people… and somewhere in there Prince2 might begin to look reasonable.
    Another analogy always comes to mind. There has been a long standing debate in paleontology circles: were the dinosaurs cold-blooded or hot-blooded? It has been argued passionately back and forth for years. One scientist made a comment that stood out for me: “You know, with an animal that big, it just doesn’t matter. It’s got so much body mass it can operate like a hot-blooded animal regardless…” At a certain size, perhaps the question becomes meaningless.
    That’s what I tend to think. At a certain size, projects form their own space, with their own rules. They are mostly overhead, because it takes that much energy just to keep such large contraptions from flying apart in different directions when they try to move “forward”.

  • http://profile.typekey.com/jurgenappelo/ Jurgen Appelo

    Rich, thanks for the comments!
    I will be addressing the subject of complex systems quite soon. The qualitive changes you mention are called “state transitions” in complexity theory. It’s very interesting stuff indeed.
    Stay tuned!

  • http://jrothman.com/blog/mpd Johanna Rothman

    Jurgen, if we were all the same, and our projects were all the same, we could have one methodology and be done with it. But we’re not and neither are our projects.
    Managers need to learn about everything and take the best from what they learn and apply that to their projects. Then they need to learn more and apply that. Never-ending cycle of learning and application.

  • http://profile.typekey.com/jurgenappelo/ Jurgen Appelo

    @Johanna: Exactly. I’ve never believed in a one-size-fits-all. However, I do believe in some fundamentals.
    For example: There are many different species, but only a few basic principles on which biological diversity is built.
    The question is: does software development have a few basic principles (and many species), and what are they?

  • pb

    public interface DoWhatIsNeeded
    void GoAboutYourBusiness(object data);
    Specific problems need specific answers, otherwise you’re just pontificating.

How to Change the World - free Workout - free