Pain/Gain Thresholds in Software Engineering
When I am down in the bowels of a software development project, I can easily spend 50 hours a week pounding at a keyboard. My wife tells me that when I am doing that, I wear a permanent look of complete puzzlement on my face.
That is what software development is all about. A constant mental struggle to find solutions to problems and a simultaneous physical struggle to get those solutions transplanted into computers with the aid of keyboard and mouse.
Like most of my artisan kith and kin, I could do without the 50 hours at the keyboard. I like to type as much text as I have to type - and no more - to get my thoughts transferred. It is one of the reasons why the expressive power and the diagnostic power of computer programming languages are so fascinating to me. Anything that involves me typing less or reading less "stuff" in order to get machines to do my bidding, the better.
All the writing and reading that goes with software development is a pain. In return for that pain, there is a gain. Namely, you can get computers to do interesting things. When pain and gain meet, you have a threshold - a pain/gain threshold. That threshold moves location from software developer to software developer and from era to era.
Take the Seventies for example. Back then, personal computers were so slow that developers had no choice but to program as close to the metal as possible. This involved a lot of typing and a lot of reading of so called "assembly language". It was a pain but the gain - applications that could run on these early computers - was worth it.
A little later, into the Eighties, personal computers became faster. Developers found that they could program a bit further from the metal - in the C programming language for example - and still produce a good application. The pain/gain threshold moved. It was no longer clear that the pain involved in programming each individual instruction to the computer directly was worth the associated gain.
A little later, personal computers became faster still. Developers found that they could program at a level higher than C - in Java and C# for example - and still produce a good application. The pain/gain threshold moved. It was no longer clear that the pain involved in managing memory allocation/de-allocation in the application directly was worth the associated gain.
A little later - about 2008 or so - personal computers became faster still thanks to the introduction of multiple processors on each chip. Developers found that they could program at a level higher than Java and C# - and still produce a good application. In fact, thanks to the design of these chips, they had no option but to change the way they wrote programs in order to take advantage of the power available to them.
The pain/gain threshold moved. It was no longer clear that the pain involved in managing threads in the application directly was worth the associated gain....
Hang on! This is 2006. I have ended up in the future with my historical analysis. How silly of me. I have introduced an era change in 2008. Still, looking forward to 2008 from 2006, it seems plausible to me. Direct thread programming to give way to higher level approaches the same way that direct memory management gave way to higher level approaches?
I suspect so. As anyone who has written any thread-based programs will tell you, there is a lot of pain you need to go through to get the performance gain. If that pain is high enough -- and I strongly suspect it is[1] -- a new era will dawn.
[1] http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html