« March of the IDEs | Main | The strategy disconnect - when guidance meets practice »

In the previous posting to this blog, I discussed how the new breed of powerful software development tools and techniques are, in fact, leading many large organizations down a very dangerous road.

In my consultancy work I have often seen organizations in which there are many different software projects covering related territory, yet without either the technical or managerial integration necessary to ensure consistency. In extreme cases, the organization itself is effectively partitioned by the very software developments which should be uniting it. Not only is this wasteful and inefficient, but in an age where statutory financial controls are being applied ever more fiercely, the existence (for example) of multiple conflicting systems of record may even lead to the downfall of the organization in question.

In the previous posting, I suggested that there is a parallel between current problems with the organization of software development and the problems of 2 decades ago with the practice of programming itself. Back then, the focus of computer science was on applying mathematical and logical techniques to improving how people wrote programs. Now, if we are to start reducing the problems caused by the explosion of new and powerful software development tools, we need to apply such techniques to improving how programmers are managed.

Is this starting to sound tediously technical to you? You may be thinking that maths and logic are the sort of things academics like to write papers on, with little relevance to the real world. Not so, unfortunately. If you have any experience of supervising, or just working in, organizations in which more than a small number of people are developing software, you will have seen some of the problems - and need to understand how to avoid them.

The crux of the problem is that large-scale collaborative efforts are unlike small-scale ones. The mathematical study of chaos theory shows how a large number of simple activities can, when taken as a whole, give rise to very complex behaviours. In order to better manage software development work, it is necessary to understand 2 key aspects of this.

First, there are tipping points. The French mathematician Rene Thom developed Catastrophe Theory in the 1960s to study how a complex system is subject to sudden changes in overall behaviour. This is a very everyday experience - one moment everything can be going fine, then suddenly it seems to be in crisis mode with no way out. Or vice-versa. What is going on? And how can it be controlled?

Thom's notion of "fixed point attractors" describes how a system may have specific points of equilibrium - points from which it can be hard to shift the system, yet between which the system may jump very suddenly under certain conditions. In a simple case, a ship can be either upright or capsized. Another classic example is equity trading, in which the value of a stock may shift dramatically in a small period of time. Further, a system may move away from an attractor without arriving at any fixed position at all - financial markets can easily descend into complete chaos, for example, which happens every now and then as we all know.

Mathematically, one can show that there is only one way to guarantee that such sudden changes will be avoided. This is to reduce the number of "controls" over the system - the number of factors affecting its behaviour. If there are too many controls, it is effectively impossible to ensure that the system does not suddenly flip from one point of equilibrium into another, and a descent into chaos at some point may well take place. However, most organizations rely for management guidance on a mixed bag of "best practices" as supplied by their various consultants, together with whatever tips people may have picked up from the latest business bestsellers - exactly the surfeit of varying control types that is most likely to lead to catastrophic behaviour. What is required is a systematic, structured approach to management, applicable at all levels and to all types of work.

Turning to the second lesson from mathematics, Benoit Mandelbrot and his "fractals" are famous for the beauty of their graphical representations. The notion is that one finds certain patterns in nature - coastlines, tree branches, and nerve fibres are among the many examples - which are built up by the repetition of a similar structure at each level. A map of a coastline at any scale will reveal the same sorts of indents and projections: bays and peninsulas have a similar shape whether they are tens, hundreds or thousands of square metres in size.

Importantly, for our purposes, fractal patterns can be observed in social life too: the same relationships and qualities apparent in small teams can be applied to large organizations and even nations. What is more, the theory of fractals shows that the application of such patterns at a small scale leads naturally to the emergence of the same patterns at a high level. In other words, if you want an organization motivated by certain aims and guided by certain behavioural principles, start small - implementing such ideas at grass roots level is not only more likely to take effect than mandating them from above, but may in itself ensure that the aims and principles are applied also at higher management levels.

TAKE AWAY

Taken together, these lessons from mathematics are the key to gaining control over the large-scale collaborative work typical of organizational software development. In future blog entries, I will explain in more detail how they can be implemented. For now, ask yourself if software development work in your own organization is guided in a structured way by a small number of sound management principles, applied equally at all levels. If not, there is trouble in store. It may even be here already, without you knowing it - if your organization is one of the many that lack either a consistent means of detecting management problems, or the means to deal with them once they have been detected.

The good news is: it is possible to rectify even the most apparently chaotic situations. Guided by the application of mathematical principles to business theory (and taking in a range of other disciplines along the way), control over any collaborative work can be regained simply by applying a small number of management techniques in a consistent fashion. To find out more, stay tuned to this blog.

Posted by keithhb in Management |Digg This|Add to del.icio.us