I’ve had extensive conversations with people about the phases of
development.  Some say the “construction” phase of a software product is
coding.  I contend that construction is actually compiling and deploying and
that everything before that is design that gets more specific with code being
the language of specific component design, and the code spells out exacting
specifications so that the compiler can appropriately construct the software
product.

So many managers in the industry have tried to reduce coding to construction
where they seek programmers who will work for what seems like hourly wages to
just “construct” the product as set forth by the designer or architect.  Maybe
sometime in the future, it may be like that, but it could only happen if the
software designers designed it completely.  In other words, the architects would
need a language far more specific than UML to design every detail of the
software.

Up to this point, the only way to design the software down to the last detail
is through code.  No design or modeling language currently can come close to
designing lower-level details.  It requires code to accomplish this, and the
coders should be just as skilled as the designers or they will have a hard time
implementing the holes in the high-level design.  Diagrams are great, but if the
coders are not highly skilled, the implementation of the code won’t fulfill the
spirit of the design and will soon become an unmaintainable mess if it even
works in the first version.

From personal observation, I don’t see this situation being rectified. 
Business managers continually come up with root cause analysis as to why it went
wrong.  They will never _discover_ that the problem is they refuse to pay what
it takes to get _good_ coders to make their software, so in the end, the company
will pay more every 5 years or so to completely replace the application that has
become unmaintainable.  The managers responsible for this waste are shielded
from accountability, of course, because of frequent corporate reorganizations. 
The first version of the software gets the job done, and the pretty UI shields
observers from the true state of the code beneath.  The design diagrams look
good in a project managers portfolio even though the software doesn’t look
anything like them.  By the time the software because unmanageable, and a
project takes off to replace the old application and “do it right this time”,
several managers have come and gone, and “no one is to blame”.  The new manager
will make a Version 1 application in the same fashion, get promoted, and several
managers down the line will repeat the same series of events.

The above is my observations from talking with others at other companies.  My
company does a better job at this (thank God), but I hear of so many other
companies where people forget the mistakes of the past and repeat them all over
again.  We, as an industry, have a lot of maturing to do.