Nice (lengthy) article about by Jack Reeves about the whether software development is engineering. If its too long for you skip to the bullet points at the end. I enjoyed much of the prose. I thought he made some interesting points…
The final goal of any engineering activity is the some type of documentation. When a design effort is complete, the design documentation is turned over to the manufacturing team. This is a completely different group with completely different skills from the design team. If the design documents truly represent a complete design, the manufacturing team can proceed to build the product. In fact, they can proceed to build lots of the product, all without any further intervention of the designers. After reviewing the software development life cycle as I understood it, I concluded that the only software documentation that actually seems to satisfy the criteria of an engineering design is the source code listings.
…There is one consequence of considering code as software design that completely overwhelms all others. It is so important and so obvious that it is a total blind spot for most software organizations. This is the fact that software is cheap to build. It does not qualify as inexpensive; it is so cheap it is almost free. If source code is a software design, then actually building software is done by compilers and linkers. We often refer to the process of compiling and linking a complete software system as “doing a build”. The capital investment in software construction equipment is low — all it really takes is a computer, an editor, a compiler, and a linker. Once a build environment is available, then actually doing a software build just takes a little time. Compiling a 50,000 line C++ program may seem to take forever, but how long would it take to build a hardware system that had a design of the same complexity as 50,000 lines of C++.
I found this article while noodling around on the old software engineering as building architecture analogy. Despite Christopher Alexander’s views on building patterns that we borrow for software patterns, I tend to agree with James Shores’ reflections on That Damned Construction Analogy:
In the software world, there is no reason for us to follow the practices of an industry limited by Newtonian laws. We have no gravity. There is no inertia. Lines of code have no weight.
If we want to dig a metaphorical hole after pouring metaphorical concrete, there’s nothing to stop us. If we want to flip the software upside down and build a foundation after we’ve built the building, we can do it. Our only limits are in our heads. Once we stop thinking that software development is like construction, we’ll have one less limitation to struggle with.
His words inspired this silly cartoon which was much cooler in my mind’s eye than it came out in pixels, but I include it here to break up the large number of words that are referenced by this post :)
I don’t quite understand how you can say software design is the source code. You can often write code without spending a whole lot of time designing, but you can also build a table without spending a lot of time designing. Building a skyscraper, however, requires tremendous amounts of design, same as building an operating system, or new crytographic routine, etc. Many RFCs are just that, designs that often have no implementations.
Compiling code is not like ‘building’ hardware. Building something, as in ‘give form to, from a plan’, is actually the coding process. Your plan is the design and it could be described mathematically, or through diagrams, or just in plain English. Someone has to build that now, make it the program.
How would you apply the compile/link analogy to byte-compiled language? or perhaps to an interpreted language. In that case, you dont even have a compiler/linker, its just reading lisp code and interpreting it. Does that mean you cannot build Lisp code?
Still interesting, thanks for a distraction :)
Say hi to Pablo for me.
I’m not completely convinced by the code-as-design theory either; however, I think the authors point is exactly that “compiling code is not like ‘building’ hardware.” With production codes so low, it changes how we think about building stuff. You can build a tree house without spending a lot of time designing too — and it may fall apart next year — just like some software built with little thought to design.
I do like his thoughts on how a lot of testing-and-debugging is done at the coding stage and how it is similar to testing done on the design of a bridge or a skyscraper.
Sarah