For a few years now, I've been claiming that the primary obstacles to software development -- and the primary methods for advancing it -- are social, not technical. This matches my interest, and it has become the focus of my work and writing.
But what if I am wrong?
Think about it for a moment. Twenty years ago, we used to ship software on floppy disks. If the software was seriously buggy, you had to send everyone a new disk. That meant the price of buggy software was a recall; the kind of thing that puts automotive manufacturers out of business.
Today, you patch the website and move on. That allows your company to take bigger risks, or, maybe, do things with less risk today that were considered very risky twenty years ago.
Compilers are better. Programming languages are better. CPUs are better.
Imagine trying to build a website with 1996 technology (Visual Basic! Apache 1.0! Perl, CGI, and HTML with TABLES! The Pentium 1 Chip!) and compete with, say, google maps, Facebook, or YouTube.
The high-tech site is going to win, right? It doesn't matter how awesome the team is with the old tech, they are going to lose.
If that doesn't convince you, try doing it with a bunch of 286's, MS-DOS, and rolling your own webserver in C - with a database back-end running off floppy disks. Or a
VIC-20, with 8K of ram and a tape drive!
You get the point. The high-tech team is going to win.
I will come back to this.
On Emotion
So last week I had a phone call with a few consultants in our greater software development community. They weren't testers, per se, but they had a lot of test knowledge, and they had interesting things to say about software process. I had hoped we could have a conversation and develop material we could re-use in some way; maybe I could quote them like I did Pete Walen in a
recent piece for CIO.com.
Right about that time, things fell completely apart.
You see, the article was on inspections, and included the famous "cost of change" graphic. My purpose in the article was to point out that the very system forces around inspections have changed, so that the value of traditional inspections is greatly decreased -- and could be negative in some cases.
And they didn't read it, because the title and content turned them off.
I can't say I blame them; the title and content do the same for me, often. The article actually started out when I had a violent reaction to an "inspections are great!" piece in an competing publication and began a letter to the editor that kept getting longer.
When they saw the topic, they turned off; when I saw it, I got incensed. I guess both reactions make sense. On the whole, theirs was probably healthier, but, hey, mine led to an article.
But I digress.
So you have this phone call, where the two parties aren't coming from the same place. Then I throw out some more terms that folks have a reaction to ("incentives" was one) without qualifying how I feel about them.
Stir, Chill, and serve, and you've got the recipe for an argument.
That's the thing about emotions and communications. If that high-tech team gets it wrong, they may develop something awesome, but it won't be what the customer needs ... that is, if they do agree enough to develop anything at all.
It turns out that people do indeed matter a great deal.
There's more to it than that
And yet ... and yet ... you still wouldn't want to deploy a web server on a
Commodore Vic-20, would you?
I suspect - just suspect - that if I've fallen to one side over the past couple of years, it has been de-emphasizing the importance of the harder engineering work. I'm not sure. A great deal of it depends on the audience, the problems they have, how the team is organized -- a lot of things.
Right now, I'm still reading Kahneman's
Thinking Fast and Slow. Preventing biases in our thinking process that cause of us to make weaker decisions - that's important.
At any given time, on any given project, I still say the primary challenges are social. Over the long hall, though, technology tends to move forward. I would submit that the strongest executing team needs to keep looking at new technologies -- as long as it wants to remain competitive.
I've always advocated a collection of power tools for testers, and adding to those tools. Right now, I'm learning
Ruby.
It may be time to put more emphasis into those tools, I'm not sure.
What do you think?