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.