Well. This post is longer than many articles, and I'm sure I could cut it, however I lack time. Here it is anyway.
I am not sure that any existing software "engineering" practice corresponds to engineering in the sense that is understood in other disciplines. In physical engineering, typically a project to build a new thing goes through a long, complex design and testing process, where ideas are discussed and prototypes built, and various different professionals (architects, engineers, manufacturing and materials specialists) take part in different stages. Only once the new thing has been established to be buildable, functional and safe is it actually built. This applies both to one off objects (bridges) and mass produced objects (microprocessors). Any change to the designed object once its built or being manufactured is considered a major undertaking in its own right, a whole separate engineering project.
If we try to draw analogies with software, the analogue of the process of manufacturing is the process of compiling the source, building an install kit and burning CDs. The analogue of the process an architect would go through with a customer of talking about the kind of building they want, and keeping an eye to implementation, is what we typically call "requirments gathering". That process is iterative, both for architects and for us, as implementation issues typically tangle up the original plan. Everything else we do is design . No, really. Read that again. Everything else we do is design. Coding is design, design is design, testing is design, "architecture" is design, even maintenance is design. By strict analogy with physical engineering, I believe this is indisputable.
There is however, as most of you no doubt know, another, more common world view, where "coding" is seem as the manufacturing process, and the actual process of manufacturing ignored as an incidental (after all, it is trivial), and "maintenance" is seen as the equivalent of stopping the girders from rusting by painting them frequently. The idea of "design" is reserved for some process, performed up-front, in cargo cult imitation of what real engineers do, by "architects" or other senior people with no contact with the code. "Coders" are considered as a particularly pesky form of overpayed semi-skilled labour.
This world view is responsible for some of the failings of the software industry as a whole. People employed as developers often don't realise that their job is to do quite a large portion of the design for the product, and fail to take responsibility for their decisions. People employed as "designers" or "architects" or (gods forbid) "analysts" produce specs that miss stuff out and fail to take feedback from "mere coders". Thus real design - actually deciding how the product should do things, and in many cases even accurately describing what it does, simply fails to get done explicitly and is done by accident by the first developer to come to it in some arbitrary way.
Software is different from physical engineering, mostly in the fact that the "manufacturing process" for software has extremely low costs. Thus you can release stuff have it break, fix it, release it again at almost zero cost to you, and in the case of open source or subscription models at almost zero cost to the customer (unless, of course, they actually tried to deploy it while it was still broken). Try doing that with a bridge. Its my view, in the end, that all software developers are engineers, since what they do are steps of the engineering process typically done by people called engineers. Its not at all clear to me what it means to engineer a program as opposed to to write one actually should mean.
Of course, I know what it typically means. In most peoples minds it means to have a separate conception of the "design" of the software which can be presented independently from code in any particular language, which covers the class structure without talking about code. Somehow, having a diagram showing the classes and their interfaces is meant to be a "better" representation of the code than the code itself.
In my view this approach is confused. I yet to have anyone clearly explain how this is meant to be helpful, or how a diagram showing the formal structure of a program (ie. UML) is meant to make sense without a complete functional description of what is being achieved. What is actually, really missing in most software products is a clear conception of what they do and how they do it, not an idea of how they are constructed. If you talk a developer on the average long-running project, one thats in "maintenance" mode, he can tell you about every single method on every single class, and talk you through the control flow in every single thread, but he cannot, usually, give a concise description of what the code actually does at a higher level of description than that of the code itself.
Having said all of that, I place myself firmly on the "engineer" side of the engineer vs tinkerer divide. I rate the people I work with, and have tried to acquire my working habits from, as consummate professionals compared with most software "engineers", and I have to say that in my view CASE tools are designed to support the software industry's cargo-cult idea of what engineering is. They represent the form of programs without representing their functions, and thus focus thought on form without function, perfectly reflecting the attitude of managers and "professionals" which aims to attain the form of "real engineering" without understanding the function.
If you disagree, post, don't moderate
[ Parent ]