Handling complexity

An essential part of Agile software development is using methods that are highly different from the old school structured development paradigm. Structured analysis/design/programming has always been all about translating a fixed set of specs into executable code. It was never meant to support change. This is what was added in object- or service-oriented development.

To get this working right, you have to give a central role to separation of concerns. Every object you make should have a clear task, which should have a low to medium complexity. Further, the best objects are designed with mainly the service it delivers to the outside world in mind.

Complexity is unavoidable in any non-trivial system. The way to attack that is to split up the complexity amongst many objects that are all of a low complexity. So rather than making an object that handles all complexity directly, you make a bunch of co-operating objects that handle the different aspects, then blend these services in a higher level object. Very often this has the added benefit of being able to use the separate sub-objects in other contexts.

An important principle is to make every service just right in terms of generality. If you make the object too general, then the interface will become huge and difficult to understand. Make it too specific and it may be easy to use, but impossible to re-use in other contexts. As always, this is part of an optimization process, where you weigh all aspects and try to find an optimum.

In the end, the main objective of using advanced design- and programming constructs should be to attack the problem of steadily increasing complexity.

In a naive system, complexity grows fast, possibly exponential. In well designed systems, complexity is the same in every part of the system. This costs work up front, meaning you will get your first results later than in the naive system. The benefits will come later in the life cycle of your software.

In OpendTect, we are now way past the cross-over point (the thin blue line above). There is no way we could have ever reached what we have now without investing daily in complexity reduction - keeping the complexity linear.