I see a few things going on in the industry over the last few years, many of them contributing to poor coding, but I do believe poor code has always been, and always will be, with us.
The most important factors are the ones noone has found a way to deal with yet. Building good software requires that someone on the project on a day to day basis have a solid mental picture of what the entire system does, and how it does it. This is the proper role of a project architect, but unfortunately this has become a synonym for "over payed, irresponsible person who doesn't write, or even understand, code." Many projects fail on this count, and thus doom themselves to bad, buggy code from the start. If noone knows what it should do, how will anyone know whether its doing the right thing ?
The second factor that will always be with us is irreducible complexity. Software is hard because it sets out to solve complex problems. There's a limit to how many people you can have working on sucha a problem, and a limit to how hard they can work. Try to put too many people on the project, or make them work too fast, and the architectural vision breaks down and the whole thing goes to pot. This goes back to Brookes, but still no senior manager in a software company seems able to resist the urge to push schedules by cutting out design and test time, or throwing inexperienced staff at late projects.
There are also some new phenomena at work. The first is a huge rise in the number of software projects, thanks to the web and corporate computerisation. This inevitably means people will be pulled into programming who lack the skills at abstract thinking that in the old days, or in acdemia today, everyone had. These people can be perfectly good programmers, but they make poor architects and designers, and this must be recognised.
Secondly, and connected to the above, is the rise of the journeyman programmer. Not everyone is a master craftsman, and not does everyone need to be. The fact this can be so is a tribute to newer tools, especially relational databases. However, once again, someone who can put together a perfectly competent database back CGI app in perl, is not necessarily competent to deal with writing a relational database themselves. Its amazing how common it it to regard programming as a single skill. It isn't, and some kinds are much harder than others.
Thirdly, software product companies suck at producing quality code. Since there are so many more of them now, this is becoming an issue. This is an inevitable aspect of their position in the market. They are so far detached from their customers, they cannot obtain requirements for new products by any means other than guesswork. Thus, once they get past a certain size, and a single architectural vision can no longer cover the whole product line, requirements thrash inevitably sets in, developers no longer know what they should be building, and code quality plummets as the source base in pulled backwards and forwards between objectives.
If you disagree, post, don't moderate