Triage with Others

December 21st, 2006 | Leaderware | Planning | Software | Growth | Time Management
bugs by Yogi

Triage, originated in the battlefield medicine, is a time honored technique for determine the priorities for bug fixing in the software industry. As Steve Pavlina puts it succinctly in his article Triage, all of us only have so much time on our hand, and in order for us to gain the most out of our time, we need to ensure that we handle only the vital tasks. Some of these vital tasks may not look urgent, but without our attention and effort, it will never come to fruition. The goal of triage is therefore to ensure that we prioritize efforts that will give us the biggest bang for the buck. I believe most of us in the software industry can readily agree to such assessment, except I am a bit puzzled with the declarations that these vital tasks actually are not urgent, because in software, these tasks are.

A generic approach to classify the bugs is to rank their severities, with severity 1 (sev 1) being the highest. Sev 1 bugs generally cause the system to malfunction, crash, causing loss of data, or even lives if the software manages something critical such as heart regulation, airplanes, etc. There is no question that these bugs deserve the highest attentions from us. Sev 2 bugs generally are defects at lesser magnitude - the system is still not fully functioning, but the impact is less drastic, and users can generally work around the problems. There are also sev 3’s (and sev 4’s) and the impacts are further decreasing. While there are no universal definitions and classifications of severities, most software teams abide by something similar.

Severities give us a starting point to determine the impact of the bug if it happened, but we also take in other considerations to assign the final priority. For example, there might be a Sev 1 bug having drastic impact, but it happens only under the most exceedingly rare conditions. And if your system is not mission critical, it might not receive the highest priority. Priorities are also ranked in ascending order; pri 1 means it must be worked on immediately; pri 2 means fixed before release, and pri 3 means fixed if there are time, so on.

In a triage meeting, people study the bugs and assess their corresponding severities and priorities. There are always disagreements on what each bug means exactly, but once people can agree on the meaning and assess the impact, severities and priorities can usually be determined without much of a fuss. Bugs are assigned out to developers for fixing and releasing back to testers for verifications. Because of the nature of software, not all bugs can be found and fixed within the release schedule, and most if not all software are released with bugs. Triage allows software teams to focus on the most important bugs and fix them to reduce the impacts.

The similarity between software triage and the battlefield medicine triage is that you need to prioritize your effort based on what you can live with. The difference is that not all bugs are equal (assuming that all lives are equal), and hence we assign most effort toward bugs that will have the highest impact. What receive the most effort? The feature we must develop in the first place.

So - what is the difference between software triage and the time management triage as described by Steve? I believe the difference is that we lack a common definition for severity and priority within time management, because we use time for multiple different functions. As we can see from the previous graph, one thing a software team can agree to is a common definition for bugs and ways to assess severities and priorities. Once they can be assessed, resources will be assigned toward the tasks.

In time management there is no such definition across all tasks. Your unenlightened boss might want to suck up all of your waking time, your friends are demanding your attention, and your family wants you to fix the leak in the toilets, at the same time you have a secret dream of becoming a rock musician, but you are afraid to share the audacious thought with anyone! No wonder prioritizing is difficult.

In software it is well recognized that subsequent enhancements and versions create the most value in the long term, and sometimes these enhancements are discovered as part of the triage process. People will suggest features for future, and these bugs are classified as sev 4 during the triage cycle, but once the software is released, the attention will be devoted toward determining which feature makes the most sense to be developed.

Your dreams for the future also deserve to be treated the same. Instead of burying them deep in your thoughts without telling anyone else, try something different; tell your boss and your family about them, and let them know that you need to devote time and effort toward fulfilling these dreams. In order for you to prioritize your time fully, you need to make sure you lay out all of the needs and balance them accordingly. Telling others will give others a chance to help you achieve the balance you need.

If you roam in an enlightened circle, people will appreciate and respect you sharing your desires. They might even be in the position to offer help; your enlightened boss might be able to alleviate some of your burdens, your understanding spouse might take on more of the chores to give you free time, and become your biggest supporter. If you do not tell them, they will just wonder why you are “disappearing” and you risk destroying things that you have taken time to build up.

But if your circle is not enlightened, telling them will allow you to know that they will not be your best support group. It might be painful, but it is something that you need to figure out in order to get closer to your dreams. After all, we all need to interact with others, and it’s much better having others supporting you than pulling your legs, right?;)

1 response so far ↓

Leave a Comment