Archive for January, 2010|Monthly archive page

Software is more like economics than physics

In Software Engineering on January 2, 2010 at 5:37 pm

I signed up as a supporter of the Software Engineering Method and Theory group because I believe that we desperately need to add rigor, science, and engineering to our discipline if we are to succeed in meeting the future demands placed upon our software systems. The main thing that caused me to back this effort is this part of the SEMAT home page:

Software engineering is gravely hampered today by immature practices. Specific problems include:

  • The prevalence of fads more typical of fashion industry than of an engineering discipline.
  • The lack of a sound, widely accepted theoretical basis.
  • The huge number of methods and method variants, with differences little understood and artificially magnified.
  • The lack of credible experimental evaluation and validation.
  • The split between industry practice and academic research.

The thing that caught my eye the most was the admission that fads have, in many cases, overridden common sense when it comes to software engineering. We, as a profession, have severe myopia in the way we adopt new methods and practices. We stumble along and when someone claims to have discovered a method that worked on a project, we rush to adopt that method without trying to identify whether the method may be appropriate for our projects. We fall for the claims that one size fits all—one approach, one set of tools will satisfy all of our needs. Companies make a business out of peddling the methods and showing customers how to correctly use it. (I was the RUP curmdgeon after all when I worked for Rational.) If a project failed, then of course the customer just didn’t do it right! It’s time to do better. We need to develop metrics and assessments that will let us identify appropriate methods based upon empirical and provable results.

One potential problem, in my opinion, for SEMAT would be if we try to develop a single theory of software engineering. We know that software systems are not like physical systems that have a well-defined set of scientific principles, or natural laws, they must follow.

It seems that some software researchers and practitioners try to create a single theory that applies to all software development. Physicists have been trying for decades to find a unified field theory, but they have not succeeded thus far. They have a lot more proven laws th start from than we do with software.

Instead of trying to model software engineering on the natural sciences, perhaps we might look to the field of economics. Economists have developed separate approaches to economic models, micro-economics and macro-economics.

Microecnomics is the study of economics on a small scale and macroeconomics is on a large scale. They are related in that general trends in either macro or micro will sometimes affect the other, but other times they can have completely opposite trends. In the general view of the two, a trend in one will be reflected in another, although sometimes on different scales. (

Perhaps there are separate approaches we need to take with respect to software: micro-software engineering and macro-software engineering. Most software engineering research and studies, including most software engineering texts, take a macro approach. They attempt to identify success factors for very large complex systems. Today, however, most software is smaller, is produced by small teams, and has a different type of complexity that must be tamed. Both the macro and micro approaches are needed. Sometimes they interact on the same project and sometimes they are mutually exclusive.

Another approach would be to consider software development as a spectrum that encompasses very small to massive projects. This has many benefits, but instead of trying to define a boundary between macro and micro software engineering, we would need to fit every method, technique, and theory to a particular band within the spectrum.

Just something I’m thinking about. More to come after I get back from Cambodia.