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.