Related link: http://www.sdexpo.com

I want to pick up essentially where I left off with my last article. Before I get into that, let me first share a little about the conference. Today, the conference officially ended. I’ve had such a broad spectrum of emotions and experiences, that it is difficult to characterize. A few of the scenes that linger in my memory have nothing to do with software development. Or do they?

Increasingly as I ponder this never ending debate about open source versus proprietary models, I’m believing more and more that our focus in the software industry is severely misguided. One of my take aways from this conference is that, very simply, that the development of a software solution is less about the technology and more about people. Before you flame this article, consider this perspective. Think for a moment about the following software development memes: user involvement in XP and agile development, user-centered development, and a new one for me from the conference, usage centered design. Consider also that one of the tracks at the conference was “People, Projects & Teams”, in addition also consider part of the description for that track: “The most important success factor for any software development team is the people that comprise it.” I think that human centered software development is applicable along many different levels. It is equally important as a key philosophy while working with developers or teams as it is working with our clients and end-users. Ultimately, the tools we use, whether they are Linux or Windows, Java or C#, or for that matter, PHP, Perl, or Python, in the end are merely tools.

I learned a new metaphor for software development at this conference. In the past I wondered whether software development was art, engineering, or manufacturing. I’ve seen this new analogy before with her Kim Polese and some her references to Doc Searls’ construction metaphor. However, this analogy became very clear from some of the keynotes and other discussions I had during the conference. So I ask the following…Do you think that carpenters get into heated discussions over what brand of hammer they use? Is one brand of lumber better than another? It might be, I have no idea. I’m a geek so how would I know?

One of the activities held during the Software Development Best Practices conference was the announcement of the Software Development Magazine 2005 Readers’ Choice Awards. So bringing up the subject of my previous article, it is extremely curious that even though I witnessed very little convergence between the Software Development Magazine conference and the Open Source community, the readers of magazine voted open source projects as recipients of approximately 25% of the awards. I’m excluding the category solely about open source, but clearly 25% of the sessions were not about open source software. So there is a little bit of a disconnect between the readers of the Software Development magazine and the organizers of the conference.

For me, my last article generated a lot of comments. I’d like to address some of those comments. From the speakers and attendees that I met, a large percentage do NOT make their living from software license fees. A considerable amount were consultants, authors, or work within an IT software development shop. If we take a moment and recall that most of the software our industry produces is never distributed nor sold with any type of license, whether proprietary or open source, then how can we claim that Open Source is jeopardizing someone’s ability to earn a living? If I happen to work in the insurance industry and I implement a web-based system using Linux and Apache, is my job at risk? Sure, maybe someone working for a producer of operating systems or web servers might be at risk, but isn’t that the basis of a market-based economy? I could just as easily choose any provider in that marketplace and it wouldn’t be seen as out of the normal.

To tie these two streams of thought together, I really believe that, whether open source or proprietary, we are all focused on creating software that is useful, used, and brings us the recognition and respect that we crave as human beings. Consistently, I think most everyone would agree that the obstacles that we confront involve our inability to understand what users want, translate their wants into a functional and usable system, and manage our teams to deliver what we believe needs to be built. I fail to see how licensing or technology plays a role in these dysfunctions. In the end, I would have to admit that my project and presentation were both centered around people, and the major problems I confronted were not technical or licensing problems, but people problems. Perhaps, just perhaps, the area most critical, and most in need of our complete attention, is not licensing or technology, but human relation engineering (or creation or constuction, choose your metaphor).

What is your metaphor for improving software development?