Because software is the youngest of engineering fields, we really don’t know what we are doing yet. As a result, there has been an ongoing Software Crisis since I wrote my first program in 1957. Over the years we have had a gaggle of silver bullets to solve the crisis – 3GLs in the ‘50s, markup and scripting languages in the ‘60s, Structured Programming in the ‘70s, RAD and object-oriented development in the ‘80s, interoperability and networking infrastructures in the ‘90s, and domain-specific programming infrastructures in the ‘00s. Each of these and many other improvements increased productivity so that the Software Crisis was temporarily alleviated. In 1960, it took a team of 1,000 programmers 10 years to create a 1 MLOC program. Today a dozen developers can churn out a 1 MLOC application in 9 months.
Yet today we still have a Software Crisis. Part of that is attributable to the fact that we solve much larger problems today. My assertion, in my role as Resident Curmudgeon, is that the bulk of the problem is far more subtle than productivity. Productivity, in the sense of minimizing keystrokes, has become an end in itself to the point where the industry, particularly IT, is so immersed in “helpful” infrastructures that it is no longer concerned that the applications produced are much larger, much slower, and much more difficult to maintain than they should be. The rest of this blog presents some of the pits and corners where I feel the software industry has placed itself.
Click button below to view the rest of the blog.
Go to Blog