I believe there has taken place an unfortunate trade off driven by market realities. In today's rapid development cycles where a piece of code may not have a very long lifetime, the quality of most code is pretty horrendous.
Background
Back in 1973 when I stated programming, computer languages and APIs were much smaller, so when one wrote a piece of code one also tended to be careful and handle most foreseeable circumstances. It was part of what made a good programmer a good programmer.
One could argue that the move from batch processing to time sharing also resulted in a general decline of the quality of code as "desk checking" code became less and less frequent and one would casually recompile code without having to have scheduled runs.
In the seventies there was a huge failed quest for formal "program verification of correctness" and code was more robust in my opinion. The development cycle was also different, there would only be two or three big pushes a year that involved working a great deal of overtime followed by a relatively calmer cycle that allowed programmers to recharge their batteries so to speak.
In the eighties working on larger, more complex systems made the use of defensive programming more necessary. Finding a random error in 50,000 to 250,000 lines of code required a disciplined approach in software construction, defensive programming. That is a program checked all its inputs for validity, checked all return calls and took effort to make sure that it could recover gracefully or signal an error correctly. This protected a function or subroutine from a change made in another part of the system later by someone else so that the code caught that error or an error that "never occurs" finally occurs. This approach had the serious downside of taking longer to develop. That is, quality software takes a longer time to develop.
The Situation Today
The APIs and language features of modern languages can be enormous. Since the development of the web, the pressure in the programming profession has become staggering. The pressure is to complete a task is constant and code has to be delivered faster and may involve greater complexity. It seems to me that to address these concerns, the actually quality of code has been negatively impacted. So much code seems to only work when everything else is "perfect". I am arguing that the code defect rates today are much higher than they used to be without any numerical data to back me up. More programmers are "sloppy" but productive. Code is hacked and not engineered and in my personal belief, object-oriented development has also facilitated this.
The promise of OO was to make problems that were previously intractable doable. It also holds the promise of object reuse but in reality many developers do not check arguments when a method may be overloaded and call methods in the base class that do no argument validation. Much OO programming is very sloppy in this writer's personal opinion. Code quality has actually declined. But one of the lessons a programmer learns is that it is more important to be done than be "right", to be 90% there rather than late and 100% there. Being done is more important than being right.
Market realities are such that it is important how quickly you get code in production or to market and this has re-enforced and encouraged these bad practices. Outsourcing means that some one can do an inferior job faster but cheaper though this is not always the case, some outsourcing is excellent in results.
Conclusion
So that reality is we are left with more complicated code with a much higher bug defect rate. Someone doing software construction the "right way", say a software house, knows the economic tradeoff between discovering defects in-house versus out in the field.
Unfortunately this appears to be a small percentage of the total programming effort and the pressure to ship fast and ship now throws much software out the door too quickly at the expense of less than optimal (that is "crappy") code.
It is my belief that most companies are unaware of the trade offs they have made or realize that this must be so in order to stay competitive.
About Me
The writer has been programming since he was 14 years old and has worked in many languages, on many system, on many operating systems; on many different projects including kernel programming, security engineering, COTS development, system integrating work and ordinary application development. He makes his home on http://www.retro-pc.com/
Article Source: http://EzineArticles.com/?expert=Denton_Burr
