What Software Development Can Learn from Other Domains?

There are recurrent claims that software is unique, it is not like any other engineering discipline, it has its vocabulary, and there is no connection between software development and management and other development and management domains. As Wolfgang Pauli was fond of saying ...

That theory is worthless, it isn't even wrong

The reason it is wrong includes:

• The argument that the materials are different is only relevant during manufacturing. There is a difference between materials and the building processes (manufacturing). But this distinction losses its importance once we move away from the keyboard where software is entered. The representation of the product is abstracted in many domains, including software, system, and news articles (UML,?SysML,?newsML)
• Other than the world where the source code is typed directly into the file, a "CAD" system is used to build the representation of the capabilities of the engineered product.
• For software, it can be an IDE. For an aero-thermal protection system, it can be a CATIA model.
• In modern "engineered" products, the product's design has a representation in the form of a collection of "objects" held in a digital form. CATIA has a database of "objects" that interact; can be asked the question - "how much do you weigh?", "how hot are you now that you're flying through the atmosphere of Mars?"; are configuration controlled; and can be "executed" to observe their dynamic behavior during use; and most importantly, can be "tested" against the needs of the customer.
• These object representations are usually built through a process of iteration on fine-grained boundaries. They are assembled incrementally, and their design and behavior is abstracted in the absence of detailed requirements.
• Yes, the construction materials differ between software, aero-thermal shells, and an office building, but the design representations are much closer than one might think. See?Notes on the Synthesis of Form, Christopher Alexander, for some background on this concept.
• Suppose we're only talking about the "manufacturing" process (coding) - the actual assembly of the engineered product. In that case, we need to catch up on most of the work involved in making these engineered products.
• The distinction between software and physical objects (of any form) becomes irrelevant when viewed as an interface management problem. This is the core concept of?Systems Engineering:
• Systems Engineering manages interfaces between software modules, hardware physical connections, and operational process interfaces. The representation of the interface is an Interface Control Document (ICD). The ICD can take the form of an object interface in Java, a pin-out interface in a cable, a bolt pattern in the thrust plate for the propulsion system, or a bolt pattern for the base plate of the cracking tower at a refinery.
• Program Managers ask questions about the capabilities of the system. These questions involve answers about the object's behavior at its interface boundary. This interface boundary is a contract between the service providers and the service users - be it a piece of code, a window frame or a spacecraft mating ring. The action that takes place at the interfaces is the mantra of Systems Engineering.
• The manner in which software projects are managed is very similar to physical projects in the real world. The software agilist paradigm can be generalized with ease. This does involve expanding one's vocabulary and semantics, but that is straightforward once one decides to do so.
• Questions like, "How much will this cost?"; "When will we be done?"; "What do I get regarding capabilities when we're done?"; "What capabilities will I get along the way?"; "How can I know we're actually making progress?"; "What is the delivered value in units of measure of dollars at this point in the project?"

Why is this view not shared by some in the software development domain?

I have my biased opinions of course:

• The world of software development discussion consists, for the most of software development ONLY, and this is likely a small subset of software activities as a whole when you look around at the embedded software, military and civil government, and COTS software domains:
• real-time control products
• industrial products
• ERP, PDM, EDM, CAD, CAM
• FPGA products that were software before they become hardware
• Software representation of virtual physical products - simulation-based procurement
• The myths perpetuated by the software community that surround the development of buildings, metal-formed products, or engineered products in general still are the basis of discussion about why software is conjectured to be different:
• Waterfall plans are the most common myth - waterfall plans are actually forbidden in FAR procurement
• Horror stories need confirmation of their validity and applicability to dominate the conversation - starting with the poorly gathered statistics of Standish. The success stories of large project development - software or otherwise - are rarely made public.
• Selling a new method into a market is nearly impossible without "felt need." So the first thing to do from a sales strategy is to create a "felt need." This starts with pointing out all the problems with the past - regardless of whether these problems are real or not - the waterfall is the carton for this sales strategy.
• Yes, there are really bad examples of project management - but there are really fat people who eat MacDonald's double cheeseburgers every day as well. There is no accounting for bone-headiness in almost any domain.

So What's the Real Problem Here?

Making the connection between software development processes and their management and the development and management of other "engineered physical products" has value in both domains:

• Learning in one field can be applied in another
• How value is measured
• How risks are addressed
• How staffs are educated
• How customers are engaged
• The representation of physical objects is becoming "soft" - the line between software and physical items is becoming blurred.
• CAD systems - form, fit, and function in the absence of real objects. This is the Digital Twin design, construction, maintenance, and operations approach.
• High-fidelity simulations - 777 certifications in the absence of a 777
• Virtual reality - construction walk-throughs in the absence of a physical building
• Simulation-based procurement - operational assessment in the absence of a real system
• Software-defined manufacturing - "build to" specification in the absence of specifications

This is a contrarian position in the agile software development world. But I'd like to know if there is time for that world to look outward a bit at what's happening in other domains. Those domains have taken the principles of agile (the agile manifesto) and applied them to non-software processes. They are in place -?lean construction?and?lean aerospace?are two of my favorites.

But suppose we, as a collective community, assert that There is absolutely NO connection between software development and construction. In that case, the marketplace has something to say about this. And as we all should know, market forces overwhelm all ideas - good or bad.