Co-evolution – Brooks did it again

In a previous post I commented about Fred Brooks’ great conference when he received the Turing Award.

In a previous post I commented about Fred Brooks’ great conference when he received the Turing Award. He named it “The Design of Design”. In that conference he spends a lot of time discussing life cycle models and explaining why the Waterfall model is wrong (“dead wrong” as he calls it). And he also presented what he thought was a better model: the co-evolutionary model, attributing it to Maher and Cross. In this model, from a Problem P1 you get a Solution S1. And from P1 and S1 you get a new problem, P2. And from P2 and S1 you get a new Solution, S2. This simple concept explains that the problem and the solution evolve in parallel. And it’s one of the good things that Agile Methods have adopted. If you use agile methods, your lifecycle model is not only iterative and incremental. It’s also co-evolutionary. Let me explain this better.

In other methods that adopt the iterative and incremental lifecycle model, the word “change” has a very strong meaning. In particular “requirements change”. These methods assume that you can define initially what you require, even if that’s only for one iteration, and they also assume that what you define initially tends to be right. If it’s not right, it only needs some “changes” that you can specify in a change request form. Well… that makes sense: for a final state to be different from an initial state there must have been a change in the middle. But in the co-evolutionary model you don’t express the new requirements as changes to the former. You just define the new problem. You rethink it now that you have a partial solution to it that gave you more insight. So, talking about a “requirements change” is difficult… it’s easier to talk about the “new problem”. Brooks tells a funny story about some changes to his house that he finally solved “thinking in a different frame of reference”. Some call it “thinking outside the box”.  “Requirement changes” mentality makes you think inside the box, in the same frame of reference.

Sometimes when we develop software, and particularly in those environments where creativity is vital, we should open our minds to rethink our problem every time we reach a partial solution. That’s like asking yourself if you want to change your question every time you get an answer for it. If you follow the “requirements change” mentality, it will be hard to do it. You will also be assuming that your first description of the problem was correct, and that it will only need to make some adjustments.

Finally, I want to say that I’m not denying here the importance of change control and, in some cases, maybe in most of the cases, of requirements change control. I can think of many types of projects where not having requirements change control can transform them into a nightmare. I can also think of cases where all this I’m proposing just doesn’t make sense due to the nature of the problem. But in many cases it does. And maybe rethinking your problem will lead you to build a great software product. So don’t forget this: when you do incremental and iterative development, consider also using a co-evolutionary approach.

Share this articleShare on LinkedInTweet about this on TwitterShare on FacebookShare on Google+Email this to someone
Go Back