Sunday, September 4, 2016

On Ego and False Dichotomy

I apparently have a memory that stretches back to the dark ages. Aside from my now-23 year old grandson asking me what King Arthur and I talked about when we had lunch (he was 5 or so at the time) a fair number of my younger colleagues firmly believe that my start working in software, on mainframes, with COBOL and RPG and JCL and other arcane (to them) things must mean I have been working with software shortly after code was written by hammering 1s and 0s into stone tablets with a hammer and chisel.

My response?  "Not quite, but close.Not as old as dirt, but I do remember when fire was a new-fangled idea."

Really. I've used that recently. This last week.

I wonder if anyone else remembers the "dark ages" where "programmers" talked with people outside of tech? You know, like, people who would actually USE the software being worked on? People who were currently using it and had an idea that might make it better? You know, an "enhancement"?

I wonder if anyone else remembers the "dark ages" where "programmers" talked with those same people and figured out things like "requirements" and "expectations" and when pieces might be available, if not the whole thing

I wonder if anyone else remembers the "dark ages" where "programmers" looked at application and system models and did the design work for how their changes, the ones they talked with non-tech people about, would fit into the whole scheme? Like, did the design and architecture work?

I wonder if anyone else remembers the "dark ages" where "programmers" looked at file systems and databases and came up with solutions that would work for their needs and not step on the toes of any other systems or the people who used them.

I wonder if anyone else remembers the "dark ages" where "programmers" figured out how to test the software they made? Figured out what the expected behavior was and how to handle situations that would, almost certainly arise when something went hay-wire or "pear-shaped." (Yeah, that is still kind of my favorite euphemism for SNAFU.) Or how about, worked hard to find faults in their presumptions?

I wonder if anyone else remembers the "dark ages" where "programmers" sat down with other programmers and worked with each other on their code? Where they went beyond "I'm stuck" and looked at "is this the best way?" Where they reviewed each others code to look for potential problems or inconsistencies - like weird variable handling or dangling If-Then constructs - or worse - random periods - dots - that might get missed?

I wonder if anyone else remembers the "dark ages" where "programmers" carefully worked out what data they needed to test with before running the first test? What conditions they needed to meet and what combinations they needed to cover - and how to cover them?

I wonder if anyone else remembers the "dark ages" where "programmers" had other "programmers" look over their shoulder as they were running tests to help them see if they missed anything?

I wonder if anyone else remembers the "dark ages" where "programmers" worked with other "programmers" before testing the work of those other "programmers"?

I don't remember when this all changed.

It was gradual. It seems like it was getting tweaked and nudged and "improved" for some time. Before long, there was "designers" and "architects" and "business analysts" and "developers" and "testers" and... yeah. Next thing I knew, people needed special treatment. They were "specialists" in something. It seems that some needed to feel "special" - more "special" than others that were not as cool as them.

People began not talking to each other so freely - or at least not as colleagues - equals. People who were "testers" seemed less at-ease to talk with "developers" as equals. Instead of working towards solutions together, they saw themselves as part of a hierarchy - a pecking-order.

There were extremely formalized models to developing software that were put in place - models to prevent people from working together (as far as I could see.) Some were focused on  "maximizing individual skills" and "reducing distractions," as far as I could see then, and still see, they were about asserting power and control.

People began to see their work as more valuable than the work other people did. They felt, possibly believed but I find most beliefs to be reassured/asserted feelings, they were better than those "others" and had greater skills than those "others" and so were worth more to the company than those "others" and so they deserved to be paid more than those "others."

This was also about the time I began noticing there were fewer women working in software shops than there used to be. I don't know if they left because they got tired of dealing with jerks or is they simply had found something better to do. I suspect one led to the other.

I began seeing more "frat-boy" behavior on teams I worked with. Behavior that would have gotten you fired a few years ago was now the norm. I did not stick at those shops very long. I apparently was not a "cultural fit." So I quit or was transferred to another team of "old people."

At the time, I was not sure what was going on. I did not like it very much. I spent my time honing skills I saw were missing in many of the "developers" I worked with. I became good at testing. I became a "tester."

A rebellion started.

People began looking for "rapid software development" and "light development methods" and ways to make software get written and developed faster, without the huge overhead imposed by the control and power folks.

I remember reading articles, then a book, on this new cool approach called "Extreme Programming."

Then I remember reading about this cool newness called "Agile." At the time, I shrugged. I still kind of shrug, frankly.

I'd seen too many "hot trends that would revolutionize software development" come and go.I did my job to the best of my ability and helped other people work better.

Then some folks got the idea that "Agile" might really be a thing. There were suddenly loads of books and papers on it. There were people talking about the "whole team" being responsible for "quality."

Whatever. For some of us, that had been the way we worked years before. Back in the "dark ages."

Now, don't get me wrong. Back in the "dark ages" there always were "programmers" who wrote code pretty well, but were better at designing solutions or figuring out file systems and structures or looking for ways to exercise the software.  Everybody was expected to do some pieces of all of this - and everybody was expected to contribute in ways that made sense.

Now, people have decided that "whole team" means "everyone must learn to code."

It took 30 years (or so... ahem) for things to come almost full circle.

I'm watching people freak out over changes where "everyone is a developer" and "developers" being made the same as... everyone else. People are freaking over that. Why?

I'm not sure. Maybe ego? Maybe there is a bit of resentment - everyone is suddenly "equal" - everyone is suddenly the same - no one is special anymore. Or worse, maybe they are not better than other people any more?

What I tend to see is this...

There are legions of people with a shallow understanding of what "whole team" means. There is a huge, potentially intentional, misunderstanding over what "whole team" means.

If everyone "learns to code" do you really expect people to be able to write production facing code in a matter of days or weeks or months? Do you really expect people to be able to develop meaningful test approaches to that code in a matter of days or weeks or months if they have never had to do so in the past?

Even in the "dark ages" there were people who were better at something than others. That is still true. Make use of those differences in skills, abilities and viewpoints.

Don't let your ego get in the way. Don't let manufactured differences and false dichotomies play on your ability to work together.

If you are not sure what I mean, consider the list of items at the beginning of this blog post.

In short:
Developers - put the ego in check and realize you can't do it all yourself;
Testers - look, you'll be treated like second-class citizens as long as you act like second-class citizens;
The rest of you - chill - do what you know how to do and help everyone else do their thing.

Act professionally. Perhaps more importantly, act as a mature adult.

Contribute to the team's success.

If your ego can't handle it, go tell your mummy I hurt your feelings.

8 comments:

  1. Great article Peter that made me think a lot about teams and roles in software development.

    My thought differ a little from your especially with your question:

    "I'm watching people freak out over changes where "everyone is a developer" and "developers" being made the same as... everyone else. People are freaking over that. Why?

    Maybe it is nothing to do with the reasons your list, more to do with what people are motivated or inclined to prefer. I have a few examples where there is great team work but people still have their own niches and training/learning.

    One from my wife who was an OR nurse.

    In an operating room you have a team of people who have to work well together. This doe snot mean the nurse performs the surgery, nor the consultant administer the anesthetic. Each person is specialized with some areas of cross over.

    Now lets look at formula one motor racing.

    You of course have the driver, you have the mechanics, the engine designer and many others that form a team each with their own area of competency.

    A could go on and list many other examples of great team work with people of different specialism.

    My question back to you is why should software development be different? Why insist we have 'jack of all trades, but master of none'?

    Diversity in teams is essential for success. Forcing people to become a generic clone does not mean you get a team culture more than likely the team with self organize into a effective team or just implode if dictated that everyone needs to be the same.

    Maybe I need to put together some longer.

    ReplyDelete
    Replies
    1. Fair question, John.

      Generally I agree in clear specializations and people need to be able to contribute particular, unique skills. The surgeon cannot be the anesthetist AND all of the nurses and others in "supporting" roles. I still find most surgeons to be painfully pompous (I have MDs & RNs & LPNs & PAs & loads of other medical folks in the family.) Those that are not are refreshing and very human.

      My concern is that in the "whole team" approach people are taking is to pretend that the last 30 years have not happened. People HAVE become specialists - like me in testing. Others are generalists. No worries. It bothers me to think that forcing everyone to "be a developer" is stupid - sorry - no other word for it.

      The way some people are interpreting "whole team" is a distortion, in my view. "Everyone being a developer" is either a semantic game or a way to eliminate people who don't fit the model in that person's mind.

      It is taking us back to where we were without the foundations that people had "way back then."

      I think we may be in agreement - and I think you may be more polite than I am.

      Delete
  2. The term I like best, is generalized specialist. For example, my strength/specialty might be in one area, like testing... but I know enough about a bunch of other stuff to be useful to the team in other ways - just perhaps not in something specific like coding production code.

    We are unique individuals, with a unique skill set, which doesn't mean we are better than anyone else.

    Whole team - working TOGETHER (using all the skills on the team) to produce a product that adds value to the customer.

    ReplyDelete
    Replies
    1. Thanks for the comment, Janet. I think we are in agreement. It seems to me that pat of the problem is looking for some sense of validation - "what I do is important" is fine as far as it goes. I have a problem when it becomes "what I do is more important than what anyone else does."

      Your last sentence in the comment is spot on.

      Thanks!

      Delete
  3. I do remember the Dark Ages! In my first programmer job, we were called 'programmer/analysts' because we did both things. We didn't know about waterfall or design. We just sat down with the people who needed the report or the online system and learned about what they wanted, showed them prototypes, and iterated til we had something good enough to release. (I'm afraid we didn't think about testing, but we could fix things so fast, it didn't matter). We developed the first online library catalog for the University of Texas this way. I learned library science!

    My definition of developer (shared by Mike Cohn) is "anyone involved in the delivery of software". Everyone on the delivery team is a developer. It doesn't mean we write code. People who specialize in writing code are programmers or coders. They are a subset of developers.

    It's true that many people don't really understand the concept that the whole team has to make a commitment to the level of quality they are comfortable with building into their software. But at least more people are talking about it.

    I'm more tired of the 'schools' of testing than I am of people saying that testers need to code. But it is all divisive. I agree we need to quit arguing about it and act. Let's experiment, let's do!

    ReplyDelete
    Replies
    1. Hi Lisa! I like that definition of "developer" - I've used versions of that in the past (and may need to steal it.)

      Thanks for the comment -

      Delete
  4. p.s. In _The Innovators_, Walter Isaacson theorizes that there were more women programmers early on because "computing" was seen as low status work. The first "computers" were humans, mostly women, who calculated things such as rocket trajectories with their brains. The glamour was all in the hardware, the "programs" involved menial work like turning switches on and off.

    I started in the days when programmers weren't paid much, and there were as many women as men, if not more women. As focus switched to software and pay went up, hiring biases kicked in. But I do agree, a lot of women I know won't put up with the death marches and harassment that is often still rampant in software teams.

    ReplyDelete
    Replies
    1. That generally describes my experience as well. When I started, programmers were paid a "reasonable" wage, no where near the "fresh out of school with no experience" expectations I'm seeing now (even allowing for inflation...) What I find bothersome is the creating of an "elite" mindset among people - which was starting to form even when I was still writing production and public facing code. There has been a growing trend of what I think of chest-thumping knuckle-dragging testosterone poisoning going on - people working crazy hours (then bragging about it) and companies feeding this by rewarding individual effort over anything else. Instead of measuring results, of the team or the individual, I see evaluation models that reward what is essentially anti-productivity, destructive behavior.

      Delete