Not so long ago, a significant portion of persons of a certain gender and a certain age range (at least in the US) were completely taken up, head-over-heels, gaga-over or enthralled by a series of novels about, yes, vampires

Yes, the un-dead, feasting on the mortals around them.  Living on the fringe of society, moving in and out with grace and ensnaring people with their obvious charms. 

Yup.  Interview With a Vampire was a really popular book and movie franchise.  


You thought I meant the Twilight series?  Really?  My oldest granddaughter (a pre- and early teen when the Twilight books first came out) certainly was enthralled by them.  My lady-wife? nah. Me? right.  Do I LOOK like someone who would be enthralled by them?  Not likely. 

Yet, the lady-wife made an observation one night as we were sitting sipping a glass of wine, and watching the 1979 film Dracula. She said “I think every time a new vampire novel or movie comes out, people who have not read or seen the earlier ones latch onto it as if this was the first time anything like that was written.”

I’ve had some conversations with testers and other software folk recently that have convinced me that the lady-wife’s view can apply to software development as much as, well, vampire novels and movies.

Part of this is time and age – Some folks of a certain age have seen the same set of ideas come around two or three times.  Slap a new label on it and standard fare from my first programming gig in the early 1980’s is all shiny and new.  Just a new buzzword.  In the meantime, there was another buzz-word label for it maybe 10 or 15 years ago. 

I’ve seen a fair number of “hot trends” in software design and development come and go and come back and go and… heh – kind of like vampires I guess.  They just WON’T STAY IN THEIR GRAVE!

Maybe that is because the underlying problem they were meant to solve was not solved.  The hot trend that replaced them that was absolutely going to solve the problem, did not solve the problem either.

I think back to how eager I was – how ready to change the software world I was – and how I tried to convince the older, kinda-stodgy folks I worked with that I had this bright and shiny new way of doing things.  One of them would sit back and tell a story from 15 years before.  I’d wonder what THAT had to do with Real MODERN software design and development – I mean, punch cards? Might as well be stone tablets, right?  Ah, the enthusiasm of youth.

As I was thinking about this, over a glass of medicinal single-malt scotch whisky last night following the local tester meeting, I got to wondering if the ideas that were bright and shiny-new for me in the early 1980’s were retreads of other ideas.  So I dug out some of my older books – stuff that was on the shelf for some time without being disturbed.  I flipped through some of them and … gads.  There they were!

I wonder if instead of vampires, these ideas were really closer to the immortals in the movie (not the TV series) Highlander – with Sean Connery playing an Egyptian in the service of King Charles V of Spain… with a Japanese katana. (Yeah, that one.)

Ideas don’t die – they can’t be killed because they are immortal.  You have to take their heads off with a sharp blade to really get rid of them.  If you don’t, they’ll go underground for a while, change their identity and then come back.  They are always there if you look carefully.  Most people don’t look carefully though.

The reason, as near as I can tell, is that the behavior – the underlying mannerisms and actions – of the humans who are developing software have not really changed since Admiral Hopper’s team discovered the first “bug” in the computer.  (I know she was not an Admiral at the time, but, you get the idea.)

Our flawed views impact our flawed behaviors which directly impacts our practices in developing software which directly impacts what we put out and what we make and how the software works and interact with humans and their flaws and imperfections and… you get the idea. 

Maybe when an enthusiastic young software person (designer, developer, tester, analyst of any sort) comes into my office with an earth-shattering idea, I may resist the urge to sit back, sip my coffee, stroke my beard and tell a story from 20 or 25 or … more years ago that leaves them wondering what anything done in COBOL on an IBM Mainframe has to do with modern software development using … fill in the blank for whatever technology your shop uses. 

What I have learned is that the technology changes.  It changes very quickly – far faster than I expected 30 years ago.  What has not changed in that time, and seemingly has not changed since the time of, well, ever – is how people make things – software in this case and how they interact with those things and each other. 

For those who have not seen anything like this, let me say quite simply.  The problem with computer software has nothing to do with the computers or the software.  The core problem is the behavior of the human persons around it – those who develop the software, design it, use it. 

It took me a long time to understand this, and I think I am beginning to see that I, and many others, have spent most of our careers trying to solve the wrong problems. 

We have been trying to use technology to address a technology problem.  The problem is not in the technology – it is the behavioral relationship we have (both developing and usiing) that technology.  Until we find a way to address that I expect we’ll continue to see bright shiny-new labels slapped on older approaches and techniques.  We will continue to have slick snake-oil sold to bosses as THE SILVER BULLET to solve all their problems.

The fact is, none of those things will work.  We need to fix the underlying problem – what we have been looking at “fixing” are the symptoms.

I think this will be an interesting journey.