If you study the objects in your everyday life, you'll realize that most of them are incredibly complex. Something as simple as paper requires a capital-intensive process industry with razor-thin margins and technology that exceeds any one person's ability to master.
It's generally understood that for example a house requires a significant collection of specialists to be built right. There's scarcely an object around that is made from scratch by one person, or even a group of people with the same skills. Everything requires close coordination of diverse specialists.
This is only barely catching on in software development. The roles of a software development team are ad hoc at best, and most organizations do a terrible job of establishing ways to coordinate their efforts.
As a result, there is a tipping point when software development efforts are overcome by complexity. Up until that point, they get by working informally together, making up deficiencies by working harder. But once the complexity goes beyond a point we can call C, everything collapses.
There are two challenges in overcoming this:
First, the problem of measuring complexity, especially before the project starts. Exceptions, interdependencies, and too many moving parts are easy to spot after the fact but are barely visible before.
Second, the problem of knowing what to do. If adding more programmers to a late software project makes it later, most savvy project managers know that the smaller the team is, the more likely it is that they will succeed. Larger teams may accomplish more, but there are diminishing returns to increasing the size. A 20--person team does not accomplish 4 times more than a 5-person team.
One way to think about the complexity of a system is to think about what it takes to fully describe it. But with information systems, fully describing it is essentially building it.
Some kind of heuristics are needed that allows developers to understand whether the complexity exceeds the "tipping point" at which they need to get very formal, very organized, and very rigid in their approach.
And then they need a team organization model that reduces the added complexity of managing their own efforts without incurring prohibitive, painful formality.
Comments