Guest Opinion
The Human Factor Always Wins Out
Welcome our new guest opinion columnist, Daniel Appleman.
You better believe there will be times in your life
When you'll be feeling like a stumbling fool
So take it from me you'll learn more from your accidents
Than anything that you could ever learn at school
-- "You're Only Human (Second Wind)" by Billy Joel
When software developers discuss software development, we spend most of our time talking about technology. We study our tools and compare their features and evaluate tradeoffs between competing technologies. We crave new features because we hope that they'll make our life just a bit easier. But such features often prove disappointing, whether because they don't deliver quite what we wanted or because they scramble our system so thoroughly that it takes us days to restore it and get back to work. We post our frustrations on blogs and forums, but always come back for more, addicts who need just one more tool to achieve happiness.
Only occasionally do we bring up other issues. We might discuss money as that rather annoying necessity that never exists in sufficient quantity. The people we talk about might be our annoying management, or those annoying programmers we manage, or that idiot client or vendor. But it's the human factor -- who we are and how we relate to technology -- that has the greatest influence over our work and our chances of success.
We all know that many software projects fail. Most studies show that more than 50 percent of all software projects are at least partial failures. Those same studies indicate that the reasons for the failures almost never relate to the technology or technological choices. The failures invariably have to do with "people" issues -- communications, politics, architecture, management, and design. If these are so critical, why do we spend so much time focusing on technology issues? The fact that there's never enough time to keep up with rapidly changing technology doesn't excuse us from taking the time to address these issues. If anything, the pace of change makes it even more important to think about how we spend our time and to make sure that we learn how to deal with the human factor.
"Officially," developers are driven by a love of technology and a passion for excellence. But scratch the surface, and you'll find more than a little bit of anxiety: Will I get that raise? Will my company make it through today's economy? Can my job be done more effectively and cheaply in another country? And how will I ever keep up with the flood of technological changes?
Scratching the surface is what I propose to do in this new, bi-monthly column. Whether I'm assessing a technology or an industry trend, or just figuring out what it means to be a software developer today, in this column technology will always come in second.
Here's an example: There's been a ton of discussion about the relative merits of Visual Basic .NET and C#. And both languages will have their place going forward. But C# will always be perceived as better. Why? Because no matter how good VB.NET gets, C# programmers will never want to use it because it makes them feel less professional. At the same time, some former VB6 developers will choose C# over VB.NET simply because it makes them feel better about themselves -- more professional, even if it isn't objectively their best technological or financial choice. Regardless of the technological issues, the human factor always wins out.
Real programmers use "C-like" languages. Unless and until the culture changes, that's the way it will be. Unless and until the culture changes … But given enough time, the culture does change, and it changes in ways unplanned and unanticipated. The next generation of developers might find our debates about VB.NET versus C# quaint and amusing.
The human factor always wins out.