Semantic Werks

Julio Leite reported on UML usage statistics, showing penetration of UML is ~23%. In an upcoming publication, Jorge Aranda surveyed small-sized software firms and found their use of modeling to be quite low, and typically of the UMLAsSketch variety. So…

Q. Why is UML so little-used, despite the fairly heavy-duty marketing and machinery behind it?

A. The long tail. See the graph below.

My contention is that of software development teams, the vast majority are working on less complex projects. For example, a month-long website redesign, a custom CRM extension, etc., etc. There are comparatively fewer working on multi-month, disruptive software systems.

Some questions, other than where can we validate such a claim.

1. How can we measure complexity? Time to completion? Size of written source code? Platforms targeted? Risk potential? Project budget? I would probably lean to project budget as a very rough guide — we all use dollars, and the cost usually reflects an a priori assumption about complexity.
2. What sorts of tools would the mushy middle of this tail need? I.e., those firms doing median complexity projects? Clearly the companies at the head of the curve don’t need the Thor’s hammer of UML or DOORS when the Owen’s* hammer of technologies like Excel do just as well. But there must be a tipping point where these technologies start to get more and more useful and important. But
3. Is there good empirical evidence that even the long-tail denizens need UML, DOORS, or Rational? Indeed, we might even expect that such large-scale firms would customize requirements management, configuration management and other helper technologies for their own purposes. This seems to be the case for Linux (GIT), NASA (SCR, formal methods, etc.), and probably others.

* Thor’s weaker and lesser-known half brother, an accountant in Little Wopping, England.

Tags: complexity, General, nasa, scr, software, uml

A software system is a human-created artifact. And yet, even though humans are in control at every stage in the process, these systems often exhibit unanticipated effects. Most attention is focused on undesirable effects, such as the Ariane 5 failure. Presumably there are also unanticipated and unexpected positive effects that we aren’t told of, for the obvious reason that things work as expected, and there is no reason to question why.

Since software is human-controlled, there should be no obvious reason to compare it to natural systems like gene networks or chemical reactions. However, as Stuart Kauffman notes in “At Home in The Universe”, humans are restricted to guessing about the future. As such, we cannot anticipate all potential scenarios. This makes human-created artifacts subject to the same randomness that many natural processes are. Consider the biological notion of ‘fitness landscape’. For a given fitness landscape there is a global maximum that describes the best adapted genotype. Clearly, we should strive to have all software reach this global maximum. But, as I have mentioned, we cannot control all the variables, since we can’t anticipate all occurences and changes in the environment. This means we can’t know ahead of time what the environment will be like when we build our software. If we knew, then we would clearly strive to build to this global maximum. Instead, we attempt to build to some pre-specified local maximum, that for us is best-adapted to our environment (see Jackson). However, even this is unlikely. For example, we may abandon certain features as deadline pressures mount. One way of looking at this is that we are changing the environment that we are targeting (abandoning requirements of the environment).

How might software mimic dynamical systems, like biological evolution? Evolution is essentially a process of striving towards these peaks in a fitness landscape. Evolving software should seek to improve its adaptation to a given set of environmental constraints (fitness pressures). The landscape shifts as new environmental constraints and conditions become known, so our software has to adapt itself (reproduce? variation? genetic drift? somehow adapt). Successful software will move to a new local maximum on the new fitness landscape. Constantly shifting environments might reflect an unstable ecology, in which maxima are impossible to find (rugged). Other landscapes might be extremely stable. For example, a long-running satellite might have very few environmental changes. We can use this landscape metaphor to model why different software seems to have different requirements.

I want to digress for a minute to discuss criticality. In small systems, we might not see any complexity effects. For example, code to post blog entries might seem easy to get mostly right (to hit a good local maximum). Why all the fuss? My contention is that at some threshold, which will change depending on what the environment is, software shifts from simple to complex. This notion is similar to laminar vs. turbulent flow in fluids. At some threshold, what was a simple-to-model system becomes nasty and impossible to predict. We need simulations and approximation algorithms to understand it. Well, I think the same is true of certain software systems. They may cross this threshold and have unpredictable effects - and this in a system in which we know all the inputs and all the outputs. Even with human control, in other words, we cannot truly control the outcomes.

Tags: complexity, evolution, General, software