Is programming really getting harder?
This summer I planted some trees in my back yard. Arizona caliche is hard, so hard that you need a jackhammer to dig a hole in a reasonable amount of time. Working a jackhammer is arguably more difficult than just using a shovel. It’s big and heavy, and you have to learn to use it properly. Sometimes the Jackhammer abstraction leaks and you need to dig an area out by hand. So if my job were to dig holes all day which would I prefer? A day using a jackhammer is easily as tiring as a day digging with a shovel, yet everybody in Arizona uses jackhammers to dig through caliche. Why? Because Jackhammers get more work done per unit time than shovels.
Joel has sparked a lot of discussion with a pair of essays about how programming is harder these days than it was years ago. My programming career has spanned a similar timespan to Joel's working with similar technologies to the ones Joel describes, yet I have to disagree with the basic sentiment that “programming is harder” today than it was ten or twenty years ago. Sure the actual labor is still challenging (just as transitioning from a shovel to a jackhammer doesn’t mean the jackhammer is easier to use) but the pace of innovation in the software field is ever so slightly higher than in the jackhammer industry, so every new generation of software is considerably more potent than the last. So even if it feels like we’re working as hard as ever we’re generally getting more done.
Joel says:
There was a time when if you read one book by Peter Norton, you literally knew everything there was to know about programming the IBM-PC.
This is like saying if I would just study the blueprints I could build my own jackhammer, which is what most developers had to do in the 80s. Norton’s book shipped in 1985, about the year I got my first PS/2. It may seem simple at first glance to point out how much “simpler” programming was then, but it was programming with a shovel - getting anything done in 1985 for the PC was hard. There was very little abstraction involved, not even abstractions like say, virtual memory, or threads. Programming was painfully direct to the hardware. Building a semi-interesting app quickly thrust you into the intricacies of different memory models and nested interrupt handlers, without the integrated debugging environments programmers are addicted to today. Making the jump from BASIC to real application programming wasn’t a “hockey stick” shape, it was more like a vertical wall.
If you look at applications from the time they seem pretty simple by today’s standards. Professional programmers spent similar amounts of time working then as they do now, but all that work just getting bytes around limited application complexity. There were various libraries you could buy to help out but they tended to be sold by little boutique vendors and were completely balkanized. Every application had to install their own print drivers. Windows was slightly better, but anyone who installed say, Trumpet WinSock on Windows 3.1 era machines knows it wasn't perfect In other words, developers spent a lot of time building their own jackhammers, which tended to be crude and misfire a lot.
Today of course computers are just a little more capable than they were in 1990. It’s nice to be able to render Quake at a ever-higher resolution but an even bigger benefit has been the emergence of ever-richer runtime environments with broad libraries for common programming problems. Today a few developers are still needed to build things like device drivers and VMs, but vastly more developers can then work in the more abstract environments. Research suggests that a given programmer can produce about x lines of code a day, where x is relatively independent of the actual language environment being used. If a developer can produce 100 lines of C code a day then he can probably produce about 100 lines of VBScript once he has similar familiarity with the environment. This is why higher-level environments tend to be more productive - a line of VBScript code does a lot more than a typical line of C.
Personally I think the heyday of really hard programming were the early 1960s, when the first big distributed electronic commerce systems like SABRE were being built. American airlines contributed the 1960 equivalent of a billion dollars to build SABRE over 5 years (I don’t know what other airlines spent). I believe these numbers and timeframe are similar to what Microsoft spent to develop the entire .NET platform. It’s hard to believe that if the airlines wanted to build a reservation system today they couldn't use mostly off-the-shelf software and get it done for 1/10 that cost (or less, I’m an optimist). Even if it feels like you have to run to stand still in this industry I think it's easier than ever to get things done.
1:01:55 AM 
|
|
