The end of the year is a time where you do some cleaning. During this activity, I found an old issue of IEEE Software where I had noticed an article as a source of interesting software development quotes about people issue. As New Year is also the time to take good resolutions, this should help us to deal with average people that we mostly are… and with the below average developers that normally will not read this ;o)

“Any construction project begins with raw material, and as Confucius suggests, the nature of the raw material is critical to success – so much that you shouldn’t even begin if the “wood” is poor. Even if you have sharp, finely honed tools, your project will still fail if the raw material isn’t sound. And what, might you ask, is the raw material of software development? Us. People. We are the only raw material of consequences in software development.

[….] So how do we prepare this material? Obviously, we don’t want it to be “rotten”, but how can we tell? How can we tell if hidden voids lurk beneath the surface, just waiting to ruin the project once we start carving? When you lack the right material, you’ll keenly feel its absence. For example, warning signs might include:

* The developer who only uses one favorite solution for every problem

* Folks who don’t learn from mistakes – or worse, are too afraid to make any

* The developer who can’t be bothered to tell anyone what he’s doing and why

[…] Painful as it is to admit it, for most people, most of the time, the problems that come up are our own fault – not the compiler’s, not the OS’s, not the database vendor’s, not our bosses’, and not our coworkers’. Yet many people and team, when facing a disastrous problem, first embark on a search (aka witch-hunt) to fix the blame. It goes somewhat against human nature, but you should always try to fix the problem, not the blame. Remember we all write software in our heads, so it makes sense to go ahead and take responsibility for it. “The cat ate my source code” just doesn’t cut it anymore – when problem come up, we need to invent options, not excuses.

[…] The isolated, lone developer huddled over a terminal with a can of highly caffeinated cola offers not only an inaccurate and misleading stereotype, but a dangerous one as well. Isolated developers can inadvertently duplicate other teammates’ work, use outdated or inappropriate methods, and even build the wrong product – at least, not the product the sponsor wanted. Instead of taking more Java and UML courses, we should work on our technical writing, public speaking, and group facilitation. A CPU with no I/O isn’t very useful. Neither is a developer who can’t communicate.”

Source: Andy Hunt and Dave Thomas, “Preparing the Raw Material”, IEEE Software, September/October 2003

My only disagreement with the authors is that I think that the end users are also essential raw material in software development, but I fully agree with the idea that we should take responsibility for our own limits. Fresh out of the University, one of the first important modification that I did created a big trouble, because I didn’t tested it with the right files, even if my supervisor suggested this to me ;o( This taught me that being confident with my work could be good… but thoroughly testing it was even better ,o)