I think you're missing some important things. It's fairly easy to write code that gets the job done and delivers the correct data/answer to the user. What is more difficult is writing that code in a way that it's maintainable. This ultimately saves money down the road and reduces technical debt. I once read that on the average, an application is rewritten from scratch every four versions. There are several factors that cause this...technology shifts is one of them...but most the reasons can be controlled. Rewriting from scratch almost always costs more and takes longer than expected. Then there is management to blame. They want hard completion dates and always ask how far along a project is, and to have it completely planned out. We've learned over the years that this waterfall planning is a major cause for over budget and over schedule projects. Agile is making big in roads into how projects are handled. Management just needs to learn that waterfall planning is a sure way to failure. Bottom line, the mess that you speak of is caused by more than just developers

The past few years I've been doing a conference presentation called "Software Gardening", that addresses these issues... how to create software ontime and on budget that meets customer needs, yet is maintainable and has little or no technical debt. It can be done. BTW, you can see my Software Gardening presentation online at http://vimeo.com/34131764.


>Today I feel we find ourselves in a programming mess. New tools constantly come out, young developers cry for more bleeding edge components, and we add layers and layers of uncessary work. We have forgotten the point of programming - to make as efficiciently as possible an application that will the needs of the indentifed user. No wonder the average end user often feels befuddled - we make work for ourselves and cloud it with obscure reasoning.
>
>What drove this home was the issue of Code magazine I just received in the mail. CODE magazine is well written; my examples could come from any similar publication. but let's use this as an example.
>
>One article was about using typescript, which is a pre-processor for Javascript. It allows you to create OO code in a way JS does not. The author is honest enough to ask why one would use this, and his answer is so that other developers in your organization, who do not know javascript well, will have an easier time following what you are doing in JS. Learn a new language, add time and money to every project, so that people will learn to read Typescript much easier than they can figure out your javascript code. Egads.
>
>Another article was about to create collections from data sources. Lots and lots of code to create classes that can read a data row and create an object in memory to manipulate. Egads again - SCATTER NAME oObject anyone? Even his extensive classes would be mjaybe 10 lines of VFP code.
>
>Another article was about using PHP to access MySQL data. The code was about 5 times longer than VFP code. Here I am willing to give a little - the requirement was to be able to run the code on Linux and Windows servers not under the client's control. I assume they have enough control to install PHP, so the requirement circumsances beg an explanation. So on second thought I may or may not give a little.
>
>The only article not like this was an article on writing code to control a microprocessor device. The article was interesting and the code examples simple (too simple, anyone could figure that code out themselves) but it broke out of the make work for ourselves mode.
>
>Logic is out the window. We learn and want to use new things for no reason other than they are new and they give us "marketable skills." The majority of IT projects finish well behind schedule and over budget -- if they finish. Fortunately, there are still some people who work to give the client what they need.