Wednesday, March 14, 2012

So Much Older Then, Or, What Was Old Is New Now

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.  

Wait. 

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.

9 comments:

  1. Given this post, you /have/ to go to PSL.

    Or at least AYE.

    ReplyDelete
  2. as someone who dreamt of being bitten by lestat when i was in my 20's, i find this post very refreshing. As my grandfather used to say, "If week after week, we complain about the cobwebs in our house. it's about time we kill that spider."

    and i'm not saying that you're old. :-)

    ReplyDelete
  3. As a fellow ( imaginary ) beard-stroker working with young whippersnappers I enjoyed this post.

    A project I was working on not long ago was running late, the PM's idea was to bring on more people so I asked him if he'd read The Mythical Man Month. Blank look and he went back to his MS Project Planner and GANNT charts

    Jerry Weinberg said "no matter what they tell you, it's always a people problem."

    How do you get these ideas known ?

    ReplyDelete
  4. Thanks Griffin - Both are on my "really REALLY do this" list.

    Perze - Was that a dream or nightmare? Might make sense in yr 20's, as one ages, the idea of immortality (or perpetual undead?) tends to lose its luster.

    Phil - I think I may have worked with the same PM, at several places. As for getting ideas out and known? Well, I'm starting with a blog post, then maybe an article or two then maybe a presentation or two, then... who knows? The problem is, those who would learn something from ay of them are not like;y (in my experience) to a) read them or b) see that it may apply to them.

    ReplyDelete
  5. I think that over the decades there's been a constant tension between software engineers and project managers (and their myriad stakeholders, accountants and contract lawyers).

    The software engineers have a pretty good understanding, through intuition and experience, of how to build good software (or at least not particularly cruddy stuff). All the good recent innovations are restatements of ancient basic truths.

    The trouble is that the approaches that produce the best results aren't easy to plan and manage, and the results aren't perfectly predictable at the start (because we don't know what we really want to do till after we've started). So techniques that are perfectly sound and rational for project management, but counter productive for software engineering, are shoehorned into the process.

    Periodically the frustration bubbles over and the good techniques that have always been known come to the fore, and project managers have to adapt to them. This is difficult and stressful, so there is eventually a reaction and the cycle continues. So maybe solutions lie not in software engineering innovation, but in more realistic financial and contractual arrangements. These drive the project managers, who in turn drive the software engineers.

    ReplyDelete
    Replies
    1. Broadly, I agree with you. I think the political decisions around software development (political here in the sense of relationships between people and groups of people) colors all of software development.

      The issue I see (or at least one) is the relationship around what is often called "business needs" and those tasked with meeting or fulfilling them. Too often, I believe, the failure begins there - failure to communicate/understand the purpose - the user rep (or sales guy) has unrealistic expectations (or sold some snake-oil and refuses to admit it), which sends the PM types into a spin, which sends development types into a spin, which bounces back with lots of questions where more non-communication happens which... you get the idea, yes?

      Delete
    2. I think so, yes. The communication problem is crucial. Software engineers historically adopted the stance of the poor bloody infantry being ordered over the top in an attack they knew was doomed. But we're supposed to be responsible professionals, so we've a duty to communicate effectively, to explain and to educate those who don't understand the problems. It's a tricky political problem, and sometimes it's not possible to get the message accepted. That doesn't absolve us of the duty to try.

      We've also tended to accept what we're told and query only the detail. Challenging requirements is crucial, and I like Tom Gilb's argument that most supposed high level requirements are in fact assumed solutions to a problem that is, at best, only dimly understood.

      Delete
  6. I wonder what would happen if you helped the young buck along to implement his new and bold idea? Act as a catalyst to speed up the process. Also create a controlled environment to limit any damage that could be done. That way when failure happens, you can help with understanding why and you point to previous attempts at trying the process. Teach the young person where to look for these things that have been tried before. Also you get time to better formulate the response to the idea.

    However, if the "new" idea somehow works, you may be creating a big problem, or you may learn something.

    Thank you for a great post Pete!

    ReplyDelete
    Replies
    1. Oh, generally I do encourage folks to try things. The bosses may not like some of these /innovations/ (but since I am not a "boss" here, no worries!)

      Experimenting and being bold and crashing tends to open people up to learning about previous versions of the same idea. Looking at these may result in some understanding as to where they went wrong, where they introduced an error, something. You've heard "nothing teaches about fire like a burned finger?" I suspect that nothing opens people to other ideas and broader learning like a spectacular failure.

      If they learn - cool. If they refuse and blame others, then they get categorized as "hoist with their own petard."

      Thanks for the comment, David!

      Delete