A recent thread in the Agile Modeling Yahoo Group has reminded me of the misconceptions surrounding Software Engineering. Let me make this clear, and I'll say it slowly and out loud for those of you at the back:
"BUILDING SOFTWARE IS NOT CONSTRUCTION!!"
Did you hear that? Want me to repeat it?
Ron Jeffries, in response to Jeff Langr, wrote,
I agree wholeheartedly with Ron - when you're building software, you're designing it. It is NOT the construction phase.
In the aviation industry, the term "design iteration" is used very frequently to describe the process of creating a new aircraft. That process is driven by feedback from many factors involved for a given aircraft, for example aerodynamic efficiency or "saleability" of a commercial aircraft. You can design a very efficient aircraft, but if no one wants to buy it you're hosed (i.e. Boeing's Sonic Cruiser!). The ability to design entire aircraft on silicon rather than paper has allowed engineers to perform vastly more iterations than before, allowing more elaborate designs than was previously possible..
This process equates very much to how we build software using an agile process. We start with a business problem to be solved and factor in the constraints from the problem domain, software and hardware infrastructure, and whether the software built is acceptable to the Customer. Improvements in hardware and our software tools have allowed us to make substantial changes to systems very quickly in order integrate feedback.
Once aluminum is cut or composites are in the autoclave, it becomes very expensive to refactor an aircraft. If a design flaw is caught early in the static or flight testing process, it's expensive to fix, but less expensive than fixing an entire fleet of production aircraft. An example here is the Boeing 777, which experienced a serious aerodynamic flutter of the nose landing gear door on the first test flight. Some redesign was necessary to strengthen the door (which had been optimized to save weight), and the updated design was incorporated into the aircraft already on the production line and all subsequent aircraft.
In software, once a system is shipped it becomes much more expensive to incorporate design changes. For example, a desktop application with thousands of installations costs a lot of money to patch. A buggy application in a cell phone is another example.
Again, the notion of "construction" in software is when the physical application is distributed, not in the creation of the software itself. That's the design process.
"BUILDING SOFTWARE IS NOT CONSTRUCTION!!"
Did you hear that? Want me to repeat it?
Ron Jeffries, in response to Jeff Langr, wrote,
Otherwise, they prefer lots of small iterations of the scientific method. Do you think there are similarities between that and TDD?
I do think that. When people think "engineering" they mostly turn their thoughts to construction, and use the analogy to decide how to "construct" software. That is almost completely incorrect. Software creation is mostly design, not construction. And engineering //design// is highly iterative in nature. It goes from sketch to
sketch ... on and on. The diagrams get more and more precise, but most of that is because the real thing is hard to build, and because the design has to be communicated to some other batch of people who will be largely clueless. The analogy does not hold in most software development, perhaps almost none.
I agree wholeheartedly with Ron - when you're building software, you're designing it. It is NOT the construction phase.
In the aviation industry, the term "design iteration" is used very frequently to describe the process of creating a new aircraft. That process is driven by feedback from many factors involved for a given aircraft, for example aerodynamic efficiency or "saleability" of a commercial aircraft. You can design a very efficient aircraft, but if no one wants to buy it you're hosed (i.e. Boeing's Sonic Cruiser!). The ability to design entire aircraft on silicon rather than paper has allowed engineers to perform vastly more iterations than before, allowing more elaborate designs than was previously possible..
This process equates very much to how we build software using an agile process. We start with a business problem to be solved and factor in the constraints from the problem domain, software and hardware infrastructure, and whether the software built is acceptable to the Customer. Improvements in hardware and our software tools have allowed us to make substantial changes to systems very quickly in order integrate feedback.
Once aluminum is cut or composites are in the autoclave, it becomes very expensive to refactor an aircraft. If a design flaw is caught early in the static or flight testing process, it's expensive to fix, but less expensive than fixing an entire fleet of production aircraft. An example here is the Boeing 777, which experienced a serious aerodynamic flutter of the nose landing gear door on the first test flight. Some redesign was necessary to strengthen the door (which had been optimized to save weight), and the updated design was incorporated into the aircraft already on the production line and all subsequent aircraft.
In software, once a system is shipped it becomes much more expensive to incorporate design changes. For example, a desktop application with thousands of installations costs a lot of money to patch. A buggy application in a cell phone is another example.
Again, the notion of "construction" in software is when the physical application is distributed, not in the creation of the software itself. That's the design process.
Comments
See Lean Construction.
Mary Poppendieck has written about this.