Systems Thinking in Software Engineering

So many things to do, so little time. This is the essence of an engineering problem. To achieve meaningful results, we need to program our activities to control the expenditure of time and resources according to plan. In most engineering disciplines, this is easily done, but not so in software engineering. This month I will try again for like the 100th time to solve a challenging software engineering problem—producing a hundred different products for a hundred different customers. This is my version of the "swing problem" shown below.

So far, I have failed, but this time around I'll be applying systems thinking principles in coming up with solutions. Although this seems to be out of the box, I think it is the correct approach to deal with the capacity and scalability issues that face me. In any case, I have done already done some small-scale "experiments" to test my ideas and I'm glad that they produced promising results. The only stumbling block I face now is the difficulty of using systems thinking notations for software engineering purposes.

Project Albatross

It's long overdue, but welcome to Project Albatross. This is a project to design and build a software factory with production lines for a variety of software products—mainly, Java and Android applications.

An Online Workspace @zotero.org

While the factory is basically virtual, it is configured for actual computers, mobile devices and network systems—and of course, operated by real people. The centerpiece of this factory is the software development process patterned after the principles of production that Peter Drucker wrote about in his 1974 book, Management: Tasks, Responsibilities, Practices. To demonstrate the use of a work structure model, we will develop a Java-based accounting system as a product platform capable of being customized for multiple industries or market segments. Then, we'll let parallel production lines assemble usable software products. (For more information, follow this project at I CodeEngineer and I ProjectEngineer.)

The Dichotomy of Software Engineering Work

Software engineering as knowledge work is mostly about the design and construction of packaged computer code. This seems obvious enough. We design how software is supposed to work and then, we build it according to specifications. This is one perspective that suggests a general sequence in the work to be done. But what if design and construction represent structure instead of a sequence? For instance, we can look at software engineering work as we would be looking at the human brain. And doing that, we would actually see knowledge work divided—left-brain work, right-brain work—with design as right-brain work and construction as left-brain work. From this perspective, we can see that there is a dichotomy between design and construction because we have two thinking processes—each with its own symbols, each with its own output.

Ashton Kutcher is the design genius

Steve Jobs in the movie Jobs (2013).

So now, we have two models—a work sequence model and a work structure model. One divides work in terms of time and the other divides work in terms of space. Which one should prevail? Actually, in project management, both are used in tandem—the project schedule divides work in terms of time while the work breakdown structure divides work in terms of space. Unfortunately, most software engineering projects are organized using a predominantly time-based model. This means that the deliverables at the end (i.e., the source code) acquire a disproportionate degree of importance compared to earlier deliverables (e.g., design documents) which are seen as unnecessary by-products. We believe this to be counterproductive and shows a lack of awareness for engineering as a discipline. What needs to be done is to recognize that this imaginary divide—the design/construction dichotomy—is structural in nature and a permanent aspect of software engineering. Of course, without empirical proof, this seems like one of many plausible explanations to a problem and appears downright rhetorical. Well, engineers that we are, we are willing to oblige with five projects to establish structure that is sorely missing in mainstream software engineering literature.