Oct 19 2009
How to divide and conquer software projects effectively
During ‘The one thing you need to know’ talk at the Agile Testing Days 09 in Berlin, Mary Poppendieck presented a summary of how software development tried to deal with complexity historically. Poppendieck started by quoting Fred Brooks, who wrote that “Complexity is the enemy in software, inherent complexity software rises exponentially”. Divide and conquer is the traditional solution to this problem, used from the first software projects and still in use today. However, the lines along which the complexity is divided changed and there is still a debate on which way is the best.
Poppendieck said that structured programming and top-down programming tried to divide software in layers around hierarchy and execution in late sixties (see Edsger Dijkstra’s work on structured programming). In the early seventies, David Parnas promoted decomposition along the lines of responsibility and likeliness of future change. In mid-seventies, Vinton Cerf and Robert Kahn designed TCP/IP by introducing a clear separation of concerns and commonality/variability analysis. In the second half of seventies software projects were being divided by process (Barry Boehm), leading to watefall development. Early eighties brought evolutionary development (Tom Gilb), building up value incrementally. (I was a bit surprised by the nineties completely missing from the story.)
Taking the best ideas from all these divisions, she said that divisions by responsibility and business value are the best.
Poppendieck compared waterfall to a “defect injection process”, saying that if specifications written first, then test and code based on those specifications by different people, the chance of them matching is very small, and there is nobody really to blame for that. She proposed that specifications should be written in the form of tests straight away, and then the code written according to these tests, to eliminate one potential cause of mismatch (specifications-tests) and ensure that the other (specifications-code) is easy to verify. This effectively is the idea behing agile acceptance testing.
see other articles from Agile Testing Days
 |
 |
A few words about a “Divide and conquer” debate: it’s OK provided it doesn’t lead to local optimizations giving no overall significant improvement or, worse, degrading global efficiency.
To some extend that could be compared to a purchase department succeeding in reducing costs by buying cheaper and/or larger stocks whereas the purchased goods are not of the required quality and/or in excess.
For more details:
- Implementing Lean Software Development by Tom & Mary Poppendieck
- The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt
Régis.
I think the nineties was about distributed computing, which later turned into Web Services. The big idea was about building up systems from collaborating subsystems through interface protocols.
I think the theme for the oughties, is the mash-up.
As for Top-Down Decomposition, the trouble the first time around was the confusion and waste in the leaf nodes of the code. Now we have Refactoring, we can clean up as we go.