There are recurrent claims that software is unique, it is not like any other engineering discipline, it has its own vocabulary, 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 the manufacturing phase. 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, 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 a aero-thermal protection system it can be a CATIA model.
- In modern "engineered" products the design of the product 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 a 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 are different between software, aero-thermal shells and an office building, but the design representations are much closer together than one might think. See Notes on the Synthesis of Form, Christopher Alexander for some background on this concept.
- If we're only talking about the "manufacturing" process (coding) - the actual assembly of the engineered product, then we're missing out 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 - interfaces between software modules, hardware physical connections, 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 system. These questions involve answers about the behavior of the object at its interface boundary. This interface boundary is a contract between the providers of the service and the users of the service - be it a piece of code, a window frame or a spacecraft mating ring. Th action 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 ones vocabulary and semantics, but that is straight forward once one decides to do so.
- Questions like, "how much will this cost?"; "when will we be done?"; "what do I get in terms of 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?"
- Mike Cohn's new book is a wonderful starting point for joining the management of software projects with the ways complex physical type projects are currently being managed. Mike describes many things that are in fact identical to how large construction and technology projects are managed. I owe Mike a book review and that will be coming soon.
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 part of software development ONLY, and this is likely a small subset of software activities in 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 became 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 dominate the conversation, without confirmation of their validity or applicability - starting with the poorly gathered statistics of Standish. The success stories of large project development - software or otherwise - are rarely made public.
- It is nearly impossible to sell a new method into a market that has no "felt need." So the first thing to do from a sales strategy it to create a "felt need." This starts with pointing out all the problems with the past - irregardless whether these problems are real or not - 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 cheese burgers everyday 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's 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
- High fidelity simulations - 777 certification 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 contraian position in the agile software development world. But I'm beginning to wonder if it is not time for that world to look outward a bit at what's going on 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 my favorites.
But if we, as a collective community, assert There is absolutely NO connection between software development and say construction - then it may well be that the market place has something to say about this. And as we all should know, market forces overwhelm all ideas - good or bad.
