The Happy Path November 2, 2009
Posted by Chuck Musciano in Random Musings.Tags: Software, Technology, Testing, Users
2 comments
In our last episode, I argued for a more consistent application of the 80/20 rule as we design and deploy software. I made an exception for testing, however, which prompted a comment asking why testing gets exempted from this rule.
As the saying goes, testing only proves the presence of bugs, not their absence. The goal of testing is to find as many of these bugs as possible before moving code into production, in the hope that we will avoid inflicting them on our poor unsuspecting users. Unlike a system in which we intentionally design and deploy the first eighty percent so as to get some value to the customers more quickly, we cannot test just eighty percent using a similar rationale. We need to test everything we build as best we can.
There is a limit, of course. You can’t test forever. The trick is to know what to test, and to test those parts thoroughly.
A co-worker of mine often talks about the “happy path.” The happy path is the path through a system where everything works, the data is correct, the system stays up, and the users are well-behaved. We tend to test the happy path first because we understand how the system should function and want to ensure that the basic features should work.
This results in testing scenarios like this
- User selects an item and adds it to their cart
- User enters billing data
- User enters shipping data
- User clicks “Check Out”
- Transaction is processed
If this works, has the system been tested? Yes. Would you move it into production? The right answer is “no,” but I’ve used a lot of systems where the apparent answer was “you bet!”
We need to move off the happy path and wander in the weeds. What if the quantity exceeds stock on hand? What if the user enters too few digits from their credit card? Or too many? Or adds a space, or a dash? What if the zip code doesn’t match the state? What if? What if? What if?
It doesn’t take long to test the happy path. It takes forever to test everything off the happy path. You need to spend a lot of time wandering away from the happy path, and maybe there is a reverse rule for testing: 20% of your time on the happy path; 80% of your time off of it.
For some reason, I was born off the happy path. Even at a young age, I was doing things like sticking Christmas lights directly into outlets (they explode and leave a mark on the wall) and riding my bike with my eyes shut (you hit parked trucks and knock yourself unconscious).
I have developed a reputation as the guy who can break things, much to the chagrin of every development team I have ever worked with. I wish I had a nickel for every time I’ve been told “no one ever tried that before.” As much as it annoys developers, people who can break things are crucial to building solid products. Better that we break them instead of a user.
We need to find and engage the non-happy-path people in our teams, and make sure that they spend a lot of time testing everything we build. Admittedly, you cannot test forever, but having the right people test for as long as possible can make a world of difference.
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio125″ only_single=false]
Knowing When To Stop October 30, 2009
Posted by Chuck Musciano in Leadership.Tags: Leadership, Management Skills, Project Management, Software, Teams, Users
6 comments
A recent issue of Wired had a great article on the concept of good enough: when products meet enough needs that consumers are happy. The author gave several examples of good enough: MP3s instead of CDs, Flip cameras instead of high-end video cameras, and even Predator drones instead of manned fighter jets. In each case, the product is woefully short of perfection, but is still so useful that the perfect alternative is being sidelined in the market space. (As an aside, you may not need to read the entire Wired article; for many of you, my summary will be good enough).
The idea of good enough is certainly not new, and is simply the latest incarnation of the 80/20 rule. Unfortunately, I think many of us who understand the 80/20 rule are still struggling to implement it in practice. It turns out it is really hard to know when to stop.
In a world of dwindling development resources, knowing when to stop is crucial to providing maximum service for the minimum investment. The moment a developer begins working on the eighty-first percentile of a project, they have gone too far. They need to be pulled off and turned loose on the first percent of the next project. This is true for everyone in the development stream: the business analysts, the designers, the infrastructure people, everyone. At some point, they are spending too much time on a project, expending effort that will not result in proportionally additional value. They need to let go and move on.
[Note that this is not true for testers. There is no 80/20 rule for testers. They need to test 100% of the 80% that has been built. More on this in another post.]
The problem is that no one knows when they have reached the eighty percent point. Very few projects have a bounded definition that makes it easy to see when enough is enough. Even when you do have such a bounded definition, user-induced scope creep can easily push that definition further and further out, dragging the eighty-percent point along with it.
It is often the case that a team will unknowingly extend the scope of a project as they work through the details of the spec. Seemingly appropriate questions lead people down paths that occupy way too much of their time. Everyone in the room knows how they got there, and why they are discussing some arcane feature, but no one was able to throw the flag and stop the process along the way. It all seems to make sense at the time.
That’s when you need a “sudden interrupter:” someone who comes to the process late, has not been a part of the incremental walk, and can easily see that things are off-track. They provide a bit of cognitive dissonance that allows the team to reset, regroup, and reassess what they are doing. Even if the group decides that they do want to continue their discussion, the pause allows them to confirm that they are on the right track.
I doubt that many people carry the title of Sudden Interrupter, but I’m beginning to think we need a few of them wandering about. Gentle challenges during any decision-making process are generally helpful, whether you are designing software or refining a budget. If nothing else, having to explain “why” to an outside observer is a constructive, cathartic exercise. So, go help someone. Interrupt them!
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio124″ only_single=false]
Infectious Diseases October 28, 2009
Posted by Chuck Musciano in Leadership, Random Musings.Tags: Attitude, Leadership, Relationships, Teams
10 comments
Many years ago, I worked with a group of software developers who were situated in a typical cube farm. One day, a woman came to work clearly not feeling well. As the morning progressed, her conditioned worsened, punctuated with repeated trips to the restroom.
Her cube neighbor was concerned that she might be carrying some infectious disease. Sure enough, as time went by, he began to feel sick himself. Soon he was running to the restroom as well, and by the end of the day they had both gone home.
It turns out that she was suffering from a bad bout of morning sickness. Her coworker, it seemed, had contracted the rarest of all airborne maladies, psychosomatic male pregnancy.
While pregnancy is tough to catch at work, other diseases spread easily. While diseases can usually be treated and disposed of, other infections can be much tougher. These kinds of infections include attitude, ethics, and courtesy.
People tend to mirror those around them. If the workplace is a sad, depressing, miserable place, everyone in it will be sad, miserable, and depressed. Happy, upbeat, pleasant places create happy, upbeat, pleasant people. The prevalent mood spreads quickly, one way or the other.
As leaders, we have tremendous control over what is in the air. Our attitude sets the tone for the team. We need to choose our attitude carefully, because it will be mimicked, consciously or unconsciously, by those around us. While maintaining a continuously Pollyannish approach isn’t going to fool anyone, genuine confident enthusiasm is a good thing.
We also need to be sensitive to the “carriers” in the group, both good and bad. Every group has a few people whose genuine positive spirit is always a welcome breath of fresh air. Their approach lifts every project, enhances every meeting, and brightens your day. These people are treasures and you need to specifically praise them for their good effect on the team.
Conversely, every group has a few Eeyores. These people find the cloud around every silver lining, know exactly why every good idea will fail, and seem to find ways to bring even the happiest person down. These people can be fatal to your organization. Oddly, many of these people have excellent technical skills, so we overlook their attitude to take advantage of their ability. We make excuses for their behavior, hoping that their technical contributions outweigh their social impact. You can do that in the short term, but you cannot tolerate it for long. A person is a whole package, and attitude problems are no more or less serious than technical or ethical ones.
As leaders, we need to remove the infectious bad attitudes from our group and allow the good attitudes to more easily spread. Who are you infecting today?
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio123″ only_single=false]
Nuts And Chocolate October 23, 2009
Posted by Chuck Musciano in Leadership.Tags: Best Of 2009, Chocolate, Nuts, Patience
1 comment so far
I really like chocolate. I also really like nuts. It is not surprising that I like nuts and chocolate together, at least in the form of a Mr. Goodbar, which blends the perfect combination of milk chocolate and peanuts into a single treat. I recently discovered, however, that I do not like dark chocolate and nuts together. In fact, they are in such conflict that taken together, they actually ruin each other.
As all aficionados know, dark chocolate is best when savored slowly, melting on your tongue. You do not chew dark chocolate; you let it dissolve in your mouth and release all its flavors over time. Nuts are a different story. They don’t melt; you have to crunch them up to release their flavor.
Mixing these two in one mouthful is a disaster. If you chew, you enjoy the nuts and turn the dark chocolate into tasteless, crumbly wax. If you let the chocolate melt, you are left with a mouthful of soggy wooden nut bits, which is no fun.
Every day, our leadership roles present us with nuts and chocolate in the form of various challenges. Some require fast, decisive action: we must chew them up and move on. Others require a more methodical approach, taking time to melt before they can be fully understood and solved.
Unfortunately, we tend to confront more nuts than chocolate in our day-to-day jobs. This conditions us to want to handle things quickly, to react and decide, to figure it out and move on. Every problem seems urgent, every concern is pressing. As we chew up the nuts, we inadvertently chew up some chocolate, creating bigger problems.
Some problems require time. In some cases, you can use that time to reflect and consider alternatives, to really seek the right response to an important issue. In other cases, some problems solve themselves if you just let them. This is especially true of interpersonal squabbles; letting people figure things out on their own is preferable to injecting yourself and trying to referee a no-win situation.
The trick, of course, is to separate the nuts from the chocolate. Waiting for nuts to melt isn’t helping anyone; you need to dive in and chew them up quickly. I’m afraid there is no simple answer to this problem. Experience is the best teacher, and comes with the requisite scars and lessons learned.
In the meantime, as you build that experience, take a moment to think about the issues that present themselves. Think through the implications of waiting versus diving in. You may find that some issues are better solved later, freeing you up to deal with the urgent ones more effectively. And while you are deciding, have a piece of chocolate. Or some nuts. But not both at the same time.
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio121″ only_single=false]
The Effective CIO 