Software engineering: and oximoron (and it will be forever)

The civil engineering principles and practises start from the obvious real fact that "it costs more (much more) to change than to create" and this undoubtable fact is reflected and it influences the entire approch.
In IT, on the other hand, the undoubtable fact is that it costs less (much less) to change than to create (at least in the short term in the life cycle of projects) and this has badly influenced the IT practises until the early time when complexity and urgency became a preminent factor.

But now we are not yet able to get rid of the Software Engineering principle in IT! We still look at it as the leading light, the guiding principles. But this is badly influencing the practise, approach and methods of IT. The early 90s heavvy methods are still here with us even thought something is moving in the right direction: MDA.
The software developement processe need to leverage its own advantages which is flexibility and adaptability instead of flighting it. The fact that is cheaper to change than to build is a value added, unque to IT because of its inner "soft" soul, it's not a deficiency to fight.
Beside the fact that in IT no one can affort to wait one or two years before having a usable software product (which is common for planning, builiding and using a bridge or a skyscraper). Let's assume that in IT we first build and then we change: it's in the human nature. In engineering practise, we first want to plan and then to build because we can not economically and practically afford to move a house or to move a window. This approach has emerged naturally more then 2000 years ago, IT is not as lucky: it is just 50 years old and we are probably now understanting how to deal with it.

Software artifacts are far more adaptable then any other hardware or concreate stuff. Let's then create an approach, process and supporting tools that not only accept this fact but also use it at the value add, the leading principle. In essence MDA is exactly doing this: creating an approach founded on "flexibility" that accepts, admits and wants IT system to be build by continuous changes. Yes it sounds like the Iterative & Incremental approach, but not as a cure to the heavvy engineering approach of IT, but as a prime strategy. In essence MDA wants to even ease and support the fact that it is cheaper to change than to build and put it as a "method".

We have to dare, and to get rid of the past approaches and go in another direction supporting a characteristic that was considered the "devil", it is in reality a good think if wrapped around a formal approach that OMG is actually defing and formalizing.

On the other hand, we shall not fall in the error of considering that MDA is "do & try", "do & fix" or "plan afterward" on the contrary: changes need to be planned. MDA, making a comparison with civil engineering, is building a development method (development here is used in a broader sense) around the uncontrovertible fact that the cost of moving a pillar is far less expensive then the cost of building it! Would we have the actual Eng. methods in civil construction, for example, if adding a story to a building would be as cheap as building it since tbe begining? Not indeed, then we have to assume the same in IT, and start all over again with a different new mindset: a tabula rasa.