Sunday, April 27, 2014

On Shrinking Violets, Anti-Heroes or Failure to Step Forward

Its been an interesting week.  Really busy at the client office and with Spring here, there is plenty of work to do in the garden at home.  This last Thursday we had a great session at the local tester meetup with Matt Heusser giving his "12 Years of Agile" presentation.  Really well received and overall a good night.

Friday night, the lady-wife and I had dinner at our favorite local Italian restaurant.  As we were eating and relaxing with a nice glass of wine, a couple we knew but had not spent much time socializing with came in.  We invited them over and had a nice chat.

At one point, the couple, another software guy, got to talking a little about work.  Not in depth, but a general list of things.  It seems he was worried and was looking to have a bit of a vent.  His concern was something I could relate to.

His projects were doing well.  His boss was giving him decent reviews.  Still, he was not terribly excited about it and generally troubled.  So as the ladies chatted about gardens and the local pottery show the next day, he and I chatted about work.

It seems that a guy at the office resigned and went on to a new gig.  Most of his projects were wrapped up pretty well and moved into production around the time he left.  One was delayed for a bunch of reasons, most were apparently not technical.  So Giovanni, they guy I was talking with, leaked something he probably did not really intend to leak.

He had worked on the project that had not been deployed.  He had done some of the interface work to connect their main system to their customer facing mobile portal.  His work had gone well, and there were no bugs or even annoyances outstanding on his work - but it was a pretty minor piece of the entire project.

OK, I said.  This seems pretty normal from my experience.  This one guy left the company and they need someone to pick up the system and keep an eye on things while its being deployed.  I've seen that happen many times and have been the one to pick up systems fairly often.  How is this a bad thing?

The answer made me blink and take a sip of Chianti - partly to buy a little time and partly to find a better response than the one that popped into my head.  (My lady-wife noticed, I don't think his wife did.  It may be a matter of being together as long as we have been.)

He said - This guy left before the project went into production.  I worked on one small piece and now they want me to be responsible for the entire thing - not just the part I worked on but everything!  Including the stuff other people worked on! 

I asked if that was a bad thing.

"YES!  Its horrible! Anything that doesn't work will be my fault!"

That called for more Chianti - another glass of it at that point.

I looked at him and smiled gently.  I asked if he thought maybe. just maybe, people thought he could take on more responsibility?  Sometimes being asked to take on a project in trouble is one way of 
saying that.  Other times its shown by replacing someone on a project who leaves the company, or, in this case, taking on an application or system that someone else had responsibility for and they have moved on - to new responsibilities or left the company.

Is it possible this is a vote of confidence in you?  An expression that your Lead or Manager think you might be ready to take the next step?

He very quietly said.  "I think they will blame me for anything that goes wrong when it actually goes into production.  If they do that then I will be in big trouble."

I smiled and asked if he really thought anyone who worked on the project would blame him if something went wrong on a part of the system that the guy who left worked on.  I asked if he thought that they product owners and key experts who had been on the project would blame him for things not working - when all the bugs found in testing, including by the same people he was worried about - had been fixed and wrapped up before things were deployed?

He looked a little panicked.  "But if my name is on as the Lead Developer in the release documents when this goes into production, and something does go wrong, other people will think I'm not very good.  I don't want that to happen.  I want this other guy's name there and then have my name listed under him as taking over from him.  They are being really unreasonable about that and saying no."

I nodded with a somber face and agreed that there was definitely a problem.  They
finished their meal and left while we lingered over cannoli and one last glass of wine.  We chatted with the owner, a friend of ours, and enjoyed the light from the setting sun in the restaurant.

So, the lady-wife looked at me and asked what was bothering me.  I said, "I think young Giovanni is making a mistake.  I think he is so afraid of being blamed that he will paint himself into a corner and never advance the way he could.  I think after this he will find himself relegated to supporting roles and never having the opportunity to run a major project.  They are handing him an opportunity to shine and he is refusing it. If Thud, Corp goes through another re-org, like they do every couple of years, I think this may be remembered and he could be out.

They want people who act boldly, not who act like shrinking violets and always want to play it safe.  We went home, played with the cats and watched a little television before turning in.  We both had to be up early the next morning.

Friday, April 18, 2014

On Testing and Wars of Religion

I'm sitting in my rocker with a nice glass of wine next to me.  Today is Friday, the 18th of April, 2014.  In Western Christian Religious calendars today is Good Friday.  It is also the anniversary of the Battles of Lexington and Concord which Americans may remember as the beginning of the American War of Independence.  Paul Revere and several others had made their midnight ride the night before.  Alas, that is another story.

The determination of how the date for Easter was to be calculated was one of the early points of contention in the Western Christian tradition.  This is an interesting point. Keep that in mind.

The granddaughter in high school had school today.  The interesting thing is that she goes to a "Christian" school.  My lady-wife found it interesting that she had school on a day of such significance in the Christian religious calendar.  I smiled and gently said "It is because of the type of Christian the school is intended to educate."

We talked on this a bit.  Simply put, I had many conversations with people of this particular sect of Christianity.  When I was young, they were the majority if kids in the neighborhood.  There was one family who were Greek Orthodox, one family around the corner who were Jewish my family and then several families of this sect.  I smiled because I remember so many times being told "You're nice and your family is nice but you're still going to Hell when you die."

OK, so consider being 11 or so and being told you would go to Hell when you died because of the way you and your family go to church.

I remember asking my mother on what was going on.  Her response was something to the effect of "They can't imagine being wrong in anything, and since we go to a different church, we must be the ones who are wrong and that means we are going to Hell."

These conversations, so many years apart, have left me thinking this evening and finding the similarities with conversations I have had with certain testers to be notable and quite disheartening.

Testing Must...

Simply put, I have been given a list of items which "Testers Must..." do if they are "really" testers.  These seem to fall under one of several forms of fallacy.  This is generally expressed as "No real <blah> would ever <do thing>."

One item commonly mentioned - Testers Must Verify Requirements.

Really?  Must?  In every circumstance?  If Tester 1 verifies requirements and does that in a day or so, what am I to do? 

I understand that when the contract says you must "provide traceability between tests and requirements" that you need to be able to do this.  Is there one and only one way to document tests and show traceability?

If there is one and only one way to document tests does this imply that any other way to document tests is wrong?

If it is wrong is it bad?  If tests are wrong as they are documented, how can we execute them and be certain that we are doing things right?

What if we are not wrong?

Does this mean we are right?

When we are challenged in our beliefs about testing, do we respond as 11 year old children or do we respond as thinking, mature adults?

What must testing do?  Are we certain?  Do we agree on this?

Based on conversations I recently had and articles I recently read, I am certain we do not agree.  When people condemn others for not agreeing with them, I get a little sad.  When I am condemned for not agreeing with them, I ask "What is it that makes you certain you are correct?"

I find that question to be challenging for people to answer.

If people can not logically explain why they believe things they believe about testing and they can not logically discuss the implications, the result sounds much like the wars of religion from 400 years ago.

Of course, in smaller ways, those wars continued through my youth.  In some places they continue.  Likewise, the wars, and condemnation about doing testing "differently" also continue.