Thursday, February 9, 2017

Gorilla Suit Testing

When I hear talk of testing in terms of requirements, I think of the Gorilla Experiment, which is cited in pretty much every book I've read in the past ten years.


Counting the passes is testing the requirements. Which are indeed important. According to the video's instructions, you had one job, so yeah, you'd better get that right.

But our customers aren't getting a copy of the requirements.  All they see is the video without the instructions, as an analogy.  And when you're not focused on the requirements, gorilla-level issues are pretty obvious.

So, you have to test your product with multiple goals and using various levels of magnification.  Once you've counted the basketballs, watch the video again and take in the big picture with no particular goals, just letting the gorillas make themselves seen.  Watch it again and see if there's anything weird going on with the team wearing black.  Watch it again, why are they in a garage in front of elevators?  Why are there S's on the wall?  Does the basketball ever change into a beach ball?

Once you've tested your requirements, congratulations, but your job is not yet finished.




Saturday, January 28, 2017

Remembering Our "Why": Lessons from the Challenger explosion

Photo Credit: NASA Goddard Space Flight Center
I always remember the anniversary of the Challenger explosion.

It has stuck with me as a sad day, not just because of the deaths of those on board and the reminder of the darker side of being an adventurous species.  But because there was evidence that they shouldn't be launching at all in weather that cold.

This evidence was presented prior to launch by an engineer, Roger Boisjoly, who worked for a NASA contractor Thiokol.  NPR released an article almost five years ago, shortly after Roger Boisjoly's death.  He and other engineers forcefully argued on January 27, 1986 to delay the launch, but NASA was "appalled" by the recommendation and the Thiokol management overruled the engineers apparently under the pressure from NASA. The launch proceeded as scheduled the next morning.
"Then, a few seconds later, the shuttle blew up. And we all knew exactly what happened."
 A few takeaways from this awful series of events that have impacted my career:
  • Find a place to work where management behaves with integrity
  • Find a place to work where management trusts the expertise of its engineers and will defer to their reasonable recommendations and predictions concerning this expertise
  • We need to be attuned to pieces/features that are subject to failure and creatively think about the conditions under which they are likely to fail, especially when they're similar to conditions that the end user will be experiencing
  • Communicate with my management and other internal stakeholders clearly about risks I see and speak with as much emphasis as I feel the risk is worth.  I do my best to let things go that ultimately don't matter so that I'm more likely to get their attention when it does.  
  • I have never needed them and I don't foresee needing them in my current position, but I have a few extra levels of freakout in reserve for "this could kill people" or "this will likely kill people", where I imagine myself trying to change the minds of those in charge of a NASA launch/no launch type of decision at various temperatures. 
I hope that customers, management, and engineers keep the lessons that can be learned from the Challenger explosion in mind as our work becomes more prevalent in life vs. death situations like driving and medical diagnoses.

Monday, January 16, 2017

A "Post-Agile" Post: "If it works, do it. If it doesn't, don't".

I like simple rules of thumb. I found an article this morning with a very simple approach to the software development life cycle: "If it works, do it.  If it doesn't, don't".

Of course, it's not exactly that simple.  What does "works" mean?

I would define "works" as delivering products that people want to pay money for at a high enough quality to meet the business value of the customer and the ethical standards we should value as technical professionals.

Underlying that is customers are paying enough money in relation to what the software company is paying its workers.  So on the revenue side, we need
  • Good market research people.  
  • Good sales and good marketing people.  
  • Good customer service folks. 
All are making sure that we understand the problems customers are facing and that the customers are and feel valued and heard.
Also underlying the simple approach is we are efficient at delivering the software on the cost side. 
  • Development/QA and product management work super closely together so that there is no question what the customer wants and why. 
  • We only deliver what the customer needs or have strong evidence that they want.  
  • Developers are all focused on current customer needs, paying down any technical debt that's accrued in the past that threatens the current value of the product, or researching future technological trends -- what customers don't need now but will in 1-5 years.  
  • QA is empowered to ask questions from the beginning and in a position to find issues quickly after they're introduced.  This prevents Development/QA from having to spend time identifying, fixing, patching, and retesting issues after the initial release.  
  • Nothing is done without the customer in mind.  No documentation that doesn't directly serve a customer or promote good understanding of the product within the company.
We still need continual, honest assessment of what we're doing that's "working" and what is "not working".  But by taking the simple approach we focus less on blindly following and enforcing specifics of a process (even an Agile process) and more on the understanding and internalizing of what "works", particularly how each of our roles and interactions contribute to the value of the product.



Friday, December 30, 2016

Self-Hacking

I've been lucky enough to have a nice chunk of vacation time at the end of 2016. 

I had a big list of to-do's piling up -- things that I want to do when I have time. And now that I "have time" they're still not done. 

Because even on vacation, I still feel pulled to do things that don't help me learn new skills or provide service to others.  I do things that are important (take walks with my kid, spend time with friends and family) and those that provide more instant visual indication of progress like cleaning out the junk drawer or a closet.

Hack 1: I need to make seemingly insurmountable things like "remain employable" and "advocate for important causes" more tangible. Something I can look at and admire, like an organized drawer.  So a certificate for a completed online class.  Or keeping a list or log of phone calls I have made or postcards I have sent.

Hack 2: I need commitment or I will find something "more important" to do.  "More important" probably meaning spending time with my kid even though she probably doesn't need as much time as I give her....Or forfeiting my allotted professional development time at work because I'm too busy doing my work tasks. But if I have a friend counting on me being at a meeting or the threat of making a bad grade in an online class, I am much more likely to do what I *say* I want to do in the first place.

In short, time is not what I need.  I need to build a schedule that commits me to doing the things I care about, with adequate slack time so that I can do the important things like cuddle with the dogs.

Wednesday, December 21, 2016

Theme for 2016: The Power of Story

I begin writing this post as an "assignment" I've taken on as part of a Toastmasters-like public speaking club a good friend of mine has organized. 

In less than three weeks, I need to give a 4-6 minute speech on any topic I want, as long as it is organized clearly.  It is Speech 2, for those of you familiar with the Toastmasters curriculum.

Anything I want, eyyyy?

What do I have to say, and why would anyone listen?

I need a story.

A memorable talk I saw (virtually) this year was Dorothy Graham's presentation at STAREast.  It was geared toward software testers but really, it was for anyone who provides information for a living.  You need to make the information relevant to them - suck them in and don't let go until they understand and are prepared to act.  You can't inform them if they're bored.  And if you don't inform them, then you're not providing value.  And if your job starts looking like a cost without benefit, it starts sticking out as low hanging fruit for workforce reduction.  While you won't be killed for failure to entertain, I see myself every day as Scheherazade in Dorothy Graham's relaying of The Arabian Nights.  Give people a reason to keep you around and they will. 

A colleague of mine continually reinforces the importance of storytelling to me.  Why would a customer care about a new feature in our software?  What tangible takeaways can we use to inspire customers enough to write a purchase order?  Or to inspire staff to go the extra mile in supporting or delighting customers?

I've even started evangelizing storytelling to others.  I was speaking with a bright eighth grader who was putting together a display for a science project, and I was advocating the importance of easy-to-read headers and blank space between thoughts rather than a Wall of Text.  I said that adults have a very short attention span.  You need to instantly tell us why we should care and provide enough incentive to read the full paper.  She worried that she wouldn't sound smart if she "dumbed down" her display.  And I said they wouldn't know anything about how smart she was if they were too bored or intimidated by her display to want to know more.  Just like that, I became a storytelling advocate. 

I started to feel like I was an agent in further reducing the attention span and appreciation for nuance.  So I'll add further that stories need to be factual and appeal to the best in us.  They need to entice you want to know more about the subject matter and inspire curiosity rather than falsely imply that everything is simple.  We need to be astute consumers of stories as the trend of storytelling spreads.
  • What is the storyteller's motive? Are they selling something? Asking for a vote?  To legitimately inform?
  • Remember that YOU are part of the story.  And you have a brain.  Ask questions. 
  • Is the story complete?  Is it true but misleading?  Does the storyteller have a good reputation for accuracy?   Inventory the emotions that the story evokes in you - Are they emotions you are proud of or are they more lizard-brain emotions you'd prefer to evolve past? 
Apparently my speech needs a closing.  I don't think I'll be able to use this as a speech, but it was fun to take a run at putting some thoughts down. 




Thursday, December 8, 2016

Ethics and persuasion

The more software continues to take over every aspect of our lives, the more important it will be for us to take a stand and ensure that our ethics are ever-present in our code.
- Bill Sourour: The code I'm still ashamed of 

I'm not asking for advice, just a hypothetical thought exercise....How do professionals take a stand?  A CYA letter to your immediate supervisor?  Voice displeasure all the way up to the CEO if necessary? Quitting? Blog about it and name names?

I'm fascinated by the process of steering my surroundings in the direction I want them to go.  Not meaning I always get my way, just that my input is included in the vector of where things end up.  Most of the time.  Sometimes there should be no compromise.  Probably. See, lots of interesting questions that play out any time a decision is made at work, at home, school, church, at a four-way stop sign, in public policy at all levels of government.

Learning how to be effective at this is difficult.  You have to win allies without alienating people.  Get people to listen and take action without making them feel scolded.  Spread information without sounding like an elitist know-it-all.  Speak with enough confidence that people know you know what you're talking about.  Read the situation to know where ground can be gained. Know how to get attention without sounding whiny.  Strike a balance between appealing to brain and heart.

Know if it's one of the rare times when just completely losing it (whatever that looks like to you) is the way to go in order to make your point.


Wednesday, December 7, 2016

Statistica, no longer part of Dell

As I mentioned in June, Dell has sold most of its software division, and now as of October 31, 2016 we old timers of StatSoft are part of Quest.  Though most of the time we'll be known as Statistica for branding purposes.

This has been quite a year.  Kind of like Saved By the Bell: The College Years...some familiar faces...some new ones...some that are noticeably absent now. Lots of change, lots the same...some of the sameness is comfortable, some of it is weird.  Some of the change is exciting, some we're still navigating through. New dynamics to learn, new energy.  Trying to transition from what we were into what we'll be a little more gracefully than Screech did. 

We are smart people.  We have a good product that we want to make even better.  We want to build features that make sense to build and to help customers solve problems. We have fun at work.  We care about each other.  We disagree sometimes about specifics but we all come to the table to work out solutions. We're curious and quirky and committed and giving.  We keep showing up with passion and integrity, and this won't change.