I have sometimes wondered whether our unconscious motive for doing so much useless work is to show that if we cannot make things work properly we can at least make them presentable.
"A builder who hides any part of the building frame, abandons the only permissible and, at the same time, the most beautiful embellishment of architecture. The one that hides a loadbearing column makes an error. The one who builds a false column commits a crime."
Contemporary architects are, however, increasingly engaging with ornamentation. The zenith was Grayson Perry and Charles Holland of FAT’s fairytale House for Essex (p64), but it does not serve as an indicator because the involvement of an artist has allowed an enhanced engagement with ornament until it surpasses mere decoration and becomes embodied in the architecture in a way that architects do not allow themselves to do. Think of FAT’s old work: the ornament is all contained within a surface - a facade - which allowed them to separate out the (Modernist) architecture from the (kitsch) superficiality of the elevation. Like Venturi before them, their ornament allowed them to have their ornamentally iced cake - and eat the Minimal Modernist sponge underneath.
Whilst Feature Parity often sounds like a reasonable proposition, we have learnt the hard way that people greatly underestimate the effort required, and thus misjudge the choice between this and the other alternatives. For example even just defining the 'as is' scope can be a huge effort, especially for legacy systems that have become core to the business.
Most legacy systems have 'bloated' over time, with many features unused by users (50% according to a 2014 Standish Group report) as new features have been added without the old ones being removed. Workarounds for past bugs and limitations have become 'must have' requirements for current business processes, with the way users work defined as much by the limitations of legacy as anything else. Rebuilding these features is not only waste it also represents a missed opportunity to build what is actually needed today. These systems were often defined 10 or 20 years ago within the constraints of previous generations of technology, it very rarely makes sense to replicate them 'as is'.