Software is a Knowledge Medium. Forget that at your Peril!

 

Legacy is something of value you leave for the next generation. At what stage in the history of Software Engineering, "legacy" has become a curse? 

Software Factory? What a heck is supposed to mean? Building software as in a production line?

Developer Productivity. The worst of all myths, introduced by maître à penser who do not have the slightest idea of what software really is. A myth perpetuated with the help of pretentious consulting firms...

Tech Debt. Another of those topics that gives you an air of expertise like an economist, but it makes no sense at all as a metaphor.

Shall I continue? A couple more:

Process as the be-all and end-all of software development, because we are persuaded that software is an engineering discipline only. You have the process, you have the product.

Aside. To my Agile friends, I am well aware of the first principle in the Manifesto. However, I spot value as a projection of what is done in the field, and not from first principles, and as a result I observe just the opposite: processes and tools often trump individuals and interactions.

So what lies at the heart of this disastrous misapprehension in our field? Read on.

I maintain that the crux of the matter lies in a profound misconception of what software really is.

1. Software is knowledge. It is the fifth medium where we store the knowledge (the other four are: DNA, Brain, Hardware Design, Books [1])
2. Software is executable knowledge. A very peculiar trait of this medium
3. Software is a cost. It is the knowledge you have to acquire, codify and deliver to get to business impacts.
4. Software is not a product. Mistaking means (coding) for ends (business impacts) is a fallacy. Go and give it a proper name!
5. The product is the codified knowledge contained in the software
6. Software is complex (intrinsically - see Brooks[2]). As such, it is not reducible to its parts as in many engineering disciplines artefacts
7. Its elasticity is a double-edged sword. As knowledge decays, software ages [3]

As a result, I'd encourage to see Software Development (SD) from a different perspective: 

1. SD is not a product-producing activity.
2. SD is a knowledge-acquisition activity.
3. Knowledge is dynamic and decaying. SD focuses on bringing down the ignorance from unknown-unknowns to first orders of ignorance. [1]
4. SD is an effort to morph knowledge into artefacts e.g. code, models, documentation, etc.
5. SD is not about coding only! The less you code to get to the business impacts, the better.
6. SD is an exercise in making continuous decisions and shaping material (knowledge is the raw material)
7. Decisions regarding what to build now, what to defer, what to invest on (by paying a little fee now), what to abandon. There are decisions you control and others you don't e.g. external stressors from the environment (see for example Residuality Theory [4])
8. Shaping material to build artefacts that responds to human needs (or as the architect Christopher Alexander would put it: create forms to fit a context) [5]
9. Wise investments in SD lie in balancing those two forces: decisions and what materials to shape accordingly. It is not a matter of being agile; rather, its mostly to do with having an economic acumen and being laser focused on business impacts.
10. SD today is in a pre-engineering phase analogous in many respects to the pre-engineering phases of the now traditional engineering disciplines.[6] This is not bad news just an urge to face reality.

 

n  Language always tells a story. Legacy, tech debt, etc. they all tell a story of a largely misconception begot by a distorted way to understand what software is. For example, we think about technical debt because we live with the assumption that software is an asset! And so on.

The last 60 years of software development are certainly only the beginning of our field and represent a short period if measured in historic terms. Nevertheless, it is helpful to try to identify some threads that could form a road map into the future. As historians usually argue, the only purpose to study history is to learn about the future. Unfortunately, our industry tends to ignore its one history.

As the software engineering profession matures, let us not fall again and again in the trap of trying to mimic or force-fit approaches that did work elsewhere, and let us looks at what makes the true nature of software, what distinguish its object, totally artificial, from that of other disciplines, closer to the natural sciences. It is engineering, but not quite the same.

***

1. Phillip G. Armour, The Laws of Software Process: A New Model for the Production and Management of Software, Auerbach Publications (2003).
2. Frederik Brooks, No Silver Bullet Essence and Accidents of Software Engineering, IEEE Computer Society, vol. 20, no. 4, pp. 10-19, April 1987
3. David Parnas, Software Aging, Proceedings - International Conference on Software Engineering, June 1994
4. Barry O'Reilly, The Philosophy of Residuality Theory, Procedia Computer Science, Vol. 184, 2021
5. Christopher Alexander, Timeless Way of Building, Oxford Press, 1979
6. R. L. Baber, Comparison of electrical "engineering" of Heaviside's times and software "engineering of our times, IEEE Annals of the History of Computing, vol. 19, no. 4, pp. 5-17, Oct.-Dec. 1997