My software developers want to use Scrum and I need to learn about Scrum really quickly.
Hamid Shojaee has created a really nice video that will take you through Scrum in about 10 minutes.
It is a really well done video. I highly recommend it.
My Subject Matter Experts (SMEs) / Business Analysts (BAs) / Quality Assurance (QA) are idiots and can’t understand how to figure out the right test case paths to test our software. Why?
People have a hard time with abstract logical implications. All people.
You learned in discrete math (or logic class) that, given that P implies Q, if you have P, then you must have Q. It’s kind of the definition of implication. In math symbols, the logical implication looks like this:
P -> Q (P implies Q)
P (P is true)
Q (There fore, Q is true)
or, in plain English
If the football game runs late, then 60 Minutes will start late.
The football game ran late.
Therefore, 60 Minutes started late.
Easy to follow, right?
Now, let’s say we turned on the TV and saw that 60 Minutes was running late. A lot of people would say, "Ah ha! The football game must have run late." And you know what? In the real world, that probably was the case. Your QA person would mark your test case as passing!
But, what if instead the President decided to talk after the game and the game had actually finished on time? Then, your conclusion that the ball game ran late would be false. Hmm . . .
So, what’s going on here?
It’s that little arrow up there in the math–the implication. It’s only one way. It says, if P then Q. It doesn’t say anything about Q. In fact, there’s no mention of the state of Q except in the result.
In English, we didn’t say, if 60 Minutes is late, then the ball game must have been late. We said, if the ball game is late, then 60 Minutes will be late. And those are two totally different statements.
If you are, you’re not alone. In fact, most people have a hard time with this–people like SMEs, BAs and QA. That’s the thing to remember. It’s a problem with people in general–not a specific person.
Don’t believe me? Read this article on the Wason Card Problem. This is a very good lesson in critical thinking. Here’s a short excerpt that might make you click the link above.
Four cards are presented: A, B, 4, and 7. There is a letter on one side of each card and a number on the other side. Which card(s) must you turn over to determine whether the following statement is false? "If a card has a vowel on one side, then it has an even number on the other side."
If you want to know the answer, spend some time reading about the problem here. If you do, you’ll learn more about yourself, people and why your SMEs, BAs and QA have a hard time with those technical requirements and creating test plans. Humans have a confirmation bias. Don’t beat them up. They are only human.
If you read the Wason Card Problem article closely, you might realize that the problem may not be in how the requirements are being interpreted; but, that you have humans interpreting them, and, as such, they are going to have a hard time with abstract concepts.
From the Wason article, when people were given the problem presented in this way,
Let the cards show "beer," "cola," "16 years," and "22 years." On one side of each card is the name of a drink; on the other side is the age of the drinker. What card(s) must be turned over to determine if the following statement is false? If a person is drinking beer, then the person is over 19-years-old.
the studies showed that people had a significantly higher chance at getting the right answer. From the article
Humans are hardwired to solve practical, concrete problems, not abstract ones.
What I have seen over the years is that software developers–abstract thinking people–tend to get involved in complicated parts of writing technical requirements. And, those parts of the requirements represent the A, B, 4 and 7 kind of cards and not the beer, cola, 16 years, and 22 years kind of cards.
This can lend to some very bad testing just because the testers simply don’t see how to prove the statement false.
Now that you’ve experienced this first hand (if you didn’t, you’ve really wasted your time and short changed yourself but it’s not too late to go back to the top and start over), consider changing your requirements a little and helping a fellow human being out. They are, after all, testing your software–ya know?
(Oh, and if you want a lesson in variability, list to this. I like the UB 40 version better than the Elvis version.)
I wonder what would happen if I did this instead of what I’m doing now?
Sometimes, when you’re coding, you’ll have an idea–a good idea. But, instead of taking the risk to implement it in the middle of what you’re doing you think to yourself, "I don’t have time to try that now . . . plus . . . I might lose what I’m in the middle of."
Of course, you can backup files and take a stab at the idea. But often times, that will require ripping out a bunch of code or shoe horning things in. Or, even worse, it might take a while to stage an environment so that you can test the idea. So, instead you just toss the idea out.
But it doesn’t have to be that way.
First of all, if you have a good idea but you’re pretty sure you can’t do anything about it, then stop and at least comment about it. It doesn’t take long and at least the idea is written down for future efforts.
However, if you’re not that constrained but don’t want to jeopardize your current environment, then just crank up a new app and play a little. Give yourself permission to do that.
I can’t tell you how many times I’ve been been walking by a cube and someone asked me, "Hey! What happens if I want to do x." My response is always, "I don’t know (even if I do). Let’s open up a new app and play a second." It gives the developer asking the question permission to play. Plus, I always end up learning something or brushing off some cobwebs. Also, it helps me to make sure someone on my team isn’t about to do something crazy.
I almost always create play apps (I even have a folder for them) as console apps. They are easy to make and most of the time I’m just trying to work out something quick and small. This "sandbox" approach is really good for working things out. You don’t have to worry about harming your existing application at all. Also, you can always refer back to the play app later if you want to extend the idea in a risk free environment or shoot it off in an email to a coworker playing around with a similar idea. I like to think of them as "sketches".
If you’re working on a large application in a very complicated area, it can take a while to get to the point in your code where you’re exploring options. Having a little application on the side that just cuts to the chase can make your work go a lot faster and will definitely move you closer to the 10 in McConnell’s 10x Software Development site.
Let’s say I’m working up a new display format for dates for one specific page in a web site that takes 5 or 6 pages to get to every time I want to test it out. It’s better for me to play in my sandbox until I get the format right and then port that deep into the application rather than working through my 5 or 6 pages on each pass. This kind of thinking is what gets you closer to the 1 in 10.
Essentially, you shouldn’t worry about wasting time so much when working in a sandbox. Exploring is part of development–even if you don’t use the code. You’ve learned something. Maybe your idea works. Maybe it doesn’t. In the end, you and your company are better for it I believe.
So, get dirty and makes some mud pies in your sandbox!
It’s been a long time since I’ve heard the term “Structured Walkthroughs”. Back in 1978, Edward Yourdon wrote a book by that name. I have the second edition of “Structured Walkthroughs“. It’s a good book. It gives you a good, human-perspective approach to critiquing other people’s work–that can get tricky sometimes.
In the late 90s, while working on large, client-server projects, we would walk a fellow coworker through our work and explain to them our approach for solving the problem we were working on. Usually, this person would be the technical lead or a more senior developer. For the most part, my walkthroughs were easy and I quickly learned the common techniques used in that shop. I was fortunate to be working with good people. That certainly makes life easier.
One habit I picked up was anticipation. As I coded, I began anticipating what my fellow coworkers would say about the solutions I was arriving at. This anticipation improved my code with respect to their standards. It made the whole process more efficient because I had less changes to make after I was done. Eventually, the quality of my code started to improve to the point that it was rare to find a bug in it. This fact didn’t go unnoticed. I got a reputation for turning in perfect code.
However, there was a small price. I ended up turning in my code a little later than most. Not much later, but enough that it didn’t go unnoticed either. I took a little extra time because I was anticipating–anticipating the walkthrough but also the QA and ultimately the customer’s looking at my finished product. I wanted it to be right–always.
Here’s a timeline graph of when thing happened with my code with respect to other developers:
Figure1: Productivity Graph
While my first delivery to QA was typically much later than most of the developers on the team, my overall delivery to the customer was much sooner because my work spent less time in QA. You can show this graph to a project manager and they’ll understand what’s going on. Doing it in real life however is a whole different story.
“Why isn’t your code in QA yet?” they’ll ask. If you’re anticipating and creating quality code, just smile and say, “it’s coming” and don’t worry. In the end, you’ll have a better result. I always do without fail.
One of the best lessons I took away from the Yourdon book was about games. Chapter 9, “Games Programmers Play” was an extension of the classic book by Ernie Berne, “Games People Play”. Basically, there are patterns that people operate under that help them to avoid responsibility for the work. Look up transactional analysis if you’re curious about these games.
However, the lesson I learned wasn’t so much about other people’s behavior–it was about mine. I learned to recognize when I was playing the games and avoiding the truth about the problems that I was solving. This helped me to stop playing the games. My productivity improved. This made life easier as you can imagine–improved self-esteem, confidence, etc.
So, the next time you get stuck with a problem or are about to turn over some code, stop playing games, grab a coworker and take them for a walk. And if you can’t find a coworker, pretend and go for a walk anyway. Over the years, I’ve created a faceless, relentless uber-coder comprised of all the authors that I respect that I take on walks through my code. He’s not for the faint of heart but if he joins you, your code will be the better for it. Give him a try sometime (imagine a deep, echoing laugh . . . moo ha ha ha).