I read a UML book a long time ago (15 or so years ago) by the inventors which said something like "software engineering should be like building a house". Meaning architects produce blue prints, and specialized workers utilize various views of them to produce their part of the end result.
When I read it, it seemed reasonable, but from my perspective - I don't think much progress has been made to that end. It might be that the goal was wrong, or unrealistic - I'm not sure...
"software engineering should be like building a house"
Only when the entire house has already been built before. Skilled carpenters and crafts people execute the same skills in different physical locations when they build houses. They don't build new kinds of buildings. They don't invent new construction techniques or materials.
Why build the same software twice? Why rebuild the same house again? Why not simply clone the software and reuse it?
The metaphor is totally broken.
Building software must involve something new or unique. If it doesn't involve something new or unique, then it's already been done and it can be copied. Problem solved.
New and Unique software features are either new technology or new use cases (or both).
If it's new technology, then the architect doesn't just create blueprints. It's new technology. First, it has to be invented. Then applied to the problem domain. That requires experience, and failed experiments, and lessons learned.
If it's a new use case, then the architect doesn't just create blueprints. It's new use. The users must be interviewed. The potential use cases tried to see if they work or don't work. Corrections and adjustments need to be made.
Also. Software is entirely design. Even what we used to call "construction" was really detailed design, and a detailed set of experiments in a narrowly-focused area. A programming language is really a design tool -- it provides a handy abstraction so we can separate our design from the chip circuitry on which it will ultimately execute.
The metaphor was totally broken. It has always been totally broken. Software is nothing like building a house.
I read a UML book a long time ago (15 or so years ago) by the inventors which said something like "software engineering should be like building a house". Meaning architects produce blue prints, and specialized workers utilize various views of them to produce their part of the end result.
That is an idealized view of actual construction work. Architects produce blueprints, which are in error and miss aspects. The civil engineer stamps it after checking it for architectural integrity, and occasionally gets it wrong. Carpenters, plumbers, et al, fix the various mistakes of the architect and engineers and work with the customer to make a pleasing building.
Have you ever heard of a house whose blueprints specified a wall where it couldn't fit? I have. Sounds a lot like software work, no?
People trot out "real" engineering fields but miss what happens there when new things are designed. Rockets had a slew of designs in the 50s and 60s. Tons of rockets exploded and performed other malfunctions. Some still do. Jet planes test pilots were dying at the rate of one per week in the 50s in the US. The Tacoma Narrows Bridge design had a critical bug in it.MIT had a unique architecture in their one of their buildings and after a few years, it was leaky and not working well... probably literally buggy. =) Keep prodding on the edge of creating and you will find flaws.
Every program you set out to write is solving a problem unique to your space, time and conundrum. Research is what you are doing when you dont' know what you are doing.
Software creation as the process gurus wish it to be is impossible by the nature of the task. Software creation has been automated, actually. We call those tools compilers.
This view has fallen out of favor for the most part. The short reason why is that when you have a software blueprint you're done. The "specialized workers" that map to the building a house metaphor would be the build script. Software development is more like making a giant blueprint, but even that metaphor isn't great.
Martin Fowler (see the Separation of Design and Construction section) has written about this for a while now, for example.
Meaning architects produce blue prints, and specialized workers utilize various views of them to produce their part of the end result.
I'd say we've reached that point decades ago: We produce blueprints (the source code) and specialized "workers" (code generators, compilers, setup software, but also people like translators, designers, documentation writers) produce their part of the end result (the final software, running on the users machine).
I think that as a concept "software engineering should be like building a house" is largely misunderstood. As a literal metaphor I kind of agree somewhat with S.Lott's answer that the metaphor appears to be broken. As a concept however, I think that the idea that software should be "engineered" just as physical constructs are "engineered" is sound, but that it requires a little perspective. Is creating software like building a house? No, and it never will be, but as the creative processes have improved and developed over time, I think that sound engineering has grown to be so integrated with what we do, that we barely recognize it for what it truly is.
Forget about how the 3 Amigos championed UML, and how building houses relies on a waterfall methodology and all that stuff. Instead of looking at the differences, look at the conceptual similarities. An architect specifies an approximation of what a house will be. He specifies a framework, but states only enough to ensure that regardless of how the blueprints are implemented, that the design will be structurally sound. This is also true of a good software architect.
While I agree that software development processes need to be highly iterative, I'm at odds with the people who believe you can create a sound software design by simply wishing it into existence after you've started coding. Even the most gung-ho Agile Warriors out there will at least have the experience to have a rough overall design in mind before they put anything down in either test or code. The advantage for the software engineer however, is that flaws in design can become quickly apparent, and that with tests in place, refactoring is easier, and a poorly factored architecture can become "better" organically, as time passes.
So to the heart of the OP's question, has any progress been made towards developing software using sound engineering practices? My answer is a resounding yes, but that it depends largely on your point of view. From my own experiences/perspective, I have seen the rise and "fall" of UML as an indication that the concept of software engineering has outgrown the need for heavily regimented design processes in terms of documentation, but that UML retains a place in the process as a means to help developers draft conceptual designs diagrammatically. This helps developers explain what they are doing to others, particularly to the lay-persons. Procedural guidelines and methodologies have sprung up in many different forms, and it is these that are the true indication of how software is engineered today. Take any agile process, and there is a focus on testing, and in most cases a test-first approach. From a design perspective, the tests are an integral part of the design process, as the tests validate the design. Specifications in the form of short "story"/"feature" statements are also a part of the engineering processes, and with the advent of the continuous integration and automated build processes that are so common today, the role of the average software developer has leaned more towards the design end of the spectrum, and left the more mundane and often repetitive tasks to be dealt with by a dedicated "robot" system.
As for the software architects out there? What is it that they really do? Again I feel that this is a role that is poorly understood because people think that architects are supposed to design everything up front. This may be true for hardware design, but where software is concerned, architects should be communicators and facilitators, and should be the people who determine how business constraints will influence the overall design of a product. If this means specifying a skeletal design up front, then this is a good thing, but the architect then needs to ensure that the rest of the product can and does grow within that framework, and that appropriate software engineering processes will be used to actually implement the product within specified guidelines.
Software development is like building a house where the new homeowners come through on the final inspection and ask that the plumbing be shifted to the other side of the structure and the order of the floors be shuffled.
To be clear: the right methodology is dependent on the problem domain (you don't use the same process for avionics and art gallery websites). That said, the vast majority of software projects out there have really benefited from the increasing adoption of agile methodologies. There is something in the nature of software that makes it impossible for people to understand what they want or what is best until they see the system work. Yes, architectural vision is essential, but modern software architectures are much more open ended and flexible than was the case in the days when UML was conceived.
One thing that shouldn't be overlooked is that the underlying technology we work with has evolved enormously and in a very good way during the past 15 years. The projects of the early to mid 1990s mostly didn't have the benefit of garbage collected memory, automatic array bounds checking, and other niceties that we take for granted. C, C++, or even assembler was often actually needed in mainstream applications in order to get performance out of hardware that we would now consider primitive and extremely limited. So the tendency to pursue waterfall or "build a house" project management strategy was a natural response to tools and development environments that were much less flexible that we enjoy today.
Thanks god they were wrong or today our work would be labelled as a simple factory worker one.
I've witnessed so many IT service companies trying to industrialize the software development process, to downsize and reduce costs, and eventually be able to offshore all the developments. Most of them have face failures with that approach.
We are more like artisans. And so can be very proud of our realisations.
I think that the founders of UML were visionary but 15 years ago the technology and hardware were not ready. Software modeling technology has changed. Eclipse and dotnet are getting better and better. There are today two different visions about UML. For IBM UML is an abstract view of the system using an MDA/MDD approach while for Omondo it should be the real world based on a single model live mapped to MOF and the code used as a component of a software factory. Both approaches are providing great value to project if used as it should be.
Hardware are now very powerful. For example my personal laptops can make more today than 10 mainframes 15 years ago, therefore graphical modeling layers can today be perfect while it was impossible before.
If you have been disapointed by UML I would say let's try again today using the latest tools and technologies.
