Keeping it clean

The bug databases which are used as they should be, are very susceptible to having a back log of old issues (bug rot). These old issues will grow and grow as time marches on. Any reasonable person who examines of the size and requests in the database results in the conclusion that they can’t all be resolved.

During a triage we ask, “When should we fix this issue?” The response typically is either, “Now” or “Next Release”. Many people are afraid to ask this question, “Will we ever fix it?” There are some issues that we will actually fix in the future, but that list will always be smaller than what we won’t fix in the future. If we are never going to fix them, why do we keep them around in an open state?

There are several reason people choose to push a bug to the “Next Release” instead of choosing not to fix it. By telling a person we aren’t planning on fixing your issue, it leads to longer triage meetings since you will have to have a more vigorous discussion on a bug closure. It is much easier to placate with a, “We’ll fix it in the future, we’ve got a release to get out the door right now”.

I’m a person who enjoys stats and the bug database. When the bug database is properly used by the developers, it is a good way for me to get a feel as to the quality and progress of a release. The result of choosing to move your issues to the “Next Release” instead of considering closure will cost you in the long run in the following ways:

Groundhog day
We have to constantly discuss these same issues again and again is insane. When we are releasing M6, we are moving many issues to M7 since we know that we won’t have time to resolve them in M6. Once we start development of M7, we go over all the M7, moving many of them to M8. Repeat this process again and again. This results in us having to discuss these same issues again and again. Those issues that we continually bump will never get fixed. Close them as “WONTFIX”, man up and just do it.

Zarro boogs found
It clutters up the view for the developers. It is much easier for a bug to get forgotten when you have 200 assigned to you, instead of only 22. Seeing that my bug list empty, is just as satisfying as all of my unit tests as green.

Component Health
Measuring the health of your components is much more difficult. With all of these old issues cluttering the database, the view of the software components health can become skewed. I could see in the database that there are 420 bugs against “Component A” which could be in a much better state than “Component B” with only 80 bugs against it.

I use the database to do bug glide slope projections to help me determine if we are converging or diverging. Carrying a large amount of bugs make the projections more cluttered.

I will say that there has been a couple of times where I’ve broken the “WONTFIX” rule. There have been requests from the senior management team which are clearly impossible (usually defying the law of physics), and no amount of discussion can get them to drop it. These bugs get logged, and targetting approatiely. We typically visit these in the begining of the release cycle to ensure that they are given due consideration so that when we can provide an intelligent response.


February 5, 2011 by · Leave a Comment
Filed under: Big Company, HR, Management 

“When you come to a fork in the road, take it.” — Yogi Berra

I have seen quite a bit of decision paralysis in many organizations. The quote above seemed to resonate with me.

Rarely in life do you ever have 100% of the data you need to make the informed decision. Sitting on your hands and waiting isn’t usually the best choice to make. Look at the situation, evaluate the potential future outcomes, and make the decision. Everyday without a decision reduces your time to act upon that decision.

To-do Lists

December 5, 2010 by · Leave a Comment
Filed under: Management, Templates 

Over the years I have experimented with many variations of to-do lists.  I’ve tried post-it sticky notes in my cube, various different GTD software, text files, and many more without success.

My greatest hope was when the GTD software was coming of age. The concept of the GTD software appeals to me, but I’ve never been able to easily tailor it to the level of detail which works best for me (and have never been able to keep up with it). I’ve found that GTD software wants me to change my way of working (and follow their philosophy) rather than allowing me to easily configure the software for the way that I work.

Each person is different and there is no one method which works best for everyone.  My method is a simple home grown method which is very light weight and fairly effective.

I have found Microsoft OneNote to be a very good electronic lab book (I often wonder why there is no Mac equivalent which is of equal quality, but I digress). I’ve explored other options, but none of them appears to be as fully functional or free form as OneNote. Inside of OneNote, I create a single page for each day’s To-do list.  Where OneNote is not an option, creating a single word file for each day has worked, but is a bit more difficult to search and I’ve had trouble inserting emails to respond to. My template contains the following sections:

This is a prioritized list of things which I need to complete. If there is a deadline, a date is associated with it.

New Items:
During the day, many tasks will get added to your list. If it is not an urgent and important task that has to be done immediately, add it to the “New Items”.

All of the items which were completed that day are placed in Done list.

Any item which you have taken off of your To-do list (or New items list) is placed here along with a reason of why it was dropped.

The usage of this method if quite straight forward.

Each morning create a new To-do list (copy the To-do list items of yesterday and clearing the work completed). Go through of yesterdays item in the “New Items” list and place it (in order) in the To-do list, or place it in the dropped list. Once all of the new items have been accepted, re-prioritize the entire To-do list and drop any of the items which are no longer relevant (or will never get done). Don’t be afraid to drop tasks. If you don’t, this list will become unmanageable. But for good measure, it is best to place a reason why it was dropped so that when you look back, you can recall why you didn’t do it.

During the day, you will get inundated with new items. As the items come in that must be worked on, add them to “New Items”. Also, as emails come in that will require responses, copy them into the todo list then move them from your inbox (which helps manage your inbox size). As work is completed, move it to the “Done” section. It is important not to delete it. You will find having a list of what has been completed very useful when you are trying to remember what you spent your time on.

This method, although imperfect, has been very effective since it contains very low overhead and it has been the only method which I’ve managed to stick with. Below is a word template for the “To-do” list.




September 1, 2010 by · Leave a Comment
Filed under: Big Company, Crazy, HR, Management, Small Company 

One of the many ways to lose good talent is to poorly execute layoffs. I’m not just talking about laying off the good people, but the manor in which you execute them that result in losing the good people.

When the employees hear of the layoffs, they should either be receiving their papers or a message from management that they’ve been completed. Having rumors running around the company or the press isn’t healthy for anyone.

Minimize the Number of Rounds
It is best to perform the minimum number of rounds possible. Best case scenario is a single round. Having round after round wears everyone out. For example, Cisco did minimal rounds, while Nortel continued to do round after round. We can’t say that the number of rounds was the reason that Nortel died, but the numerous rounds of layoffs at Nortel didn’t help the situation.

It is important not to forget that each round of layoffs is another round of overtures from your competition to your best employees. A question for you is, how many times can your people resist the competing offers?

Survivor Compensation
This is a tough one. Many times when I’ve been involved in layoffs, they’ve followed with raises (or stock/options to a lesser extent) for some of the remaining people. On one hand, it is a way showing your remaining employees that you value them. But on the other hand, some employees would have preferred that more people be saved rather than increasing compensation.

This one really depends on the team and the circumstances.

Voluntary Layoffs
I recall reading some folklore sometime where when one company did layoffs they booked two meeting rooms. A mass email was sent out saying that the company was considering layoffs and would be providing two information sessions. The company intentionally schedule both sessions at the same time. Session A was geared towards people who wanted the layoff, while session B was targeted for those who wanted to keep their jobs. When the layoffs occurred, everyone in session A was kept, while B was let go. This would never happen in the real world, but illustrates the example that some of your highly employable employees may consider having your company pay them to move to the competition.

We can also find numerous Dilbert comics out there where it highlights that you are paying your best and brightest to leave the company.

All Clear

Many employees want to know when the layoffs have completed and they can have a feeling of security. After they have completed, if they are completed, it is wise to tell everyone that you don’t have any plans to do more layoffs. In reality, all employees should know that the present and future cash position of the company typically dictates the headcount (Eg. If the numbers for next quarter aren’t met, the layoffs could occur next round no matter what was said last quarter).

Ensure Ted gets Whacked
Every team has some under performers (If you don’t know who in your team it is, it could be you) who I call Ted. It is best to ensure that all the Teds are let go before any of the others. This may seem obvious, but in the real world, some Teds always seem to survive the first few rounds. If you have any influence in the layoffs, your job is to ensure that Ted gets it before anyone else. Improper selection will demoralize the remaining staff, and also make the person who appears to be responsible for candidate selection look like an idiot.

Try to resume business and operations back to normalcy soon afterwords. After the layoffs, re-assure people as much as possible while being fully truthful. You do not want to be back in this situation at the end of the next quarter having this same conversation.

Are we there yet

WeThereAsking developers on an hourly basis if they are done, will NOT make the fix come faster. Just because you are receiving pressure from above, doesn’t give you a license to kill productivity for all of those around you. Now is when you need to control the situation and get things done by helping your team. This is not the time to request for up to the minute status updates and TPS reports. Interrupting your developer’s concentration constantly doesn’t help them work. Try the following instead:

  • Make sure the correct amount of people are dedicated to the problem. There are many times when less is more (I’m not just talking about the editor), where the right two people are infinitely more effective than the wrong 20 people.

  • Distractions must be minimized to ensure their focus doesn’t drift from the current work to other priorities.

  • Provide the stakeholders with accurate updates on progress. If there is any heat or anger related to the issue, take it for the team so that they can focus on fixing the issue.

  • Ensure the developers understands the issue, context, and time lines.

  • Remove roadblocks soon as quickly as you can (or ahead of time if possible).

  • Get the developers what they need to get the job done right.

Clear the path in front of them and let them work, don’t hold them back.

Students – The Many Month Interview

The purpose of students is recruiting for full time employees. Their work terms are their interview. At the end of the term, you will have a good idea if they would fit into your organization.

Many companies have a probationary period, but it is usually not long enough to evaluate the effectiveness of the employee. With students, you have a 4 to 18 month term. Students will leave at the end of the term unless you ask them to stay. Full timers stay at the end of the probation term unless you ask them to leave (which usually tones of paper work).

Many people say, students are cheap. I would say that this needs to be clarified. Students are a cheap way to recruit new hires, but expensive when you factor in training from your full timers. Here are some of the costs associated with hiring students:

Resume Reading – I’ve found that marks are not necessarily the best judge of future work place performance. There have been many good people I’ve worked with who have had mediocre marks. The reason I bring up marks is that the filers offered by the schools for the employers are typically useless, resulting in a huge pile of resumes. Multiply this by the number of schools you are hiring from, then you start to see that this starts to add up.

Interviewing – The interview process for students goes much faster than full timers, but you will still need to dedicate half a day to a full day depending on the number of schools and candidates that have been selected.

Work Plan – With most students, I spend time to create a work plan for the term. This plan contains the training plan, ramp up information, and outline of their work for the term. This plan will be added as a template to the template section.

Training – People must be assigned to train this new resource, not manuals. This training (or interruptions) of your regular team members daily activities will reduce their productivity.

Salary – The salary of the student is lower than your full timers. Make sure to talk to accounting if you are in a small company as there may be government grants available to help subsidize their salary.

Now that you’ve got the student, it is important to give them real work. No one enjoys make work projects. The purpose of the student is to help determine if they are material to be a full time hire. This is best evaluated by giving them work just as if they were a regular employee.

Once the work term is over, you should have a good idea if they would make a good full time hire. When you bring this person on full time, their is much less risk and training.

Note: On the government student hiring incentives, there are many strings attached. Ensure that the accounting department doesn’t dictate that the new hires must qualify for the program. I have seen some programs structured so that a student who is in a coop program is unable to qualify as a new student hire because the qualification formula used involves number of hours worked over a period (which can be exceed by those in a coop program).

The developers will rise up

February 7, 2010 by · Leave a Comment
Filed under: Crazy, Development, Management 

For those of you not from a technical background, dealing with technical people may seem a bit alien. This is the story of what happened when Cara (who reported into the sales organization) attempted to run a technical project.

I don’t recall Cara’s title, but she was the interface between the customer and the development team. We were working on a customization of our product for the customer, so there was a to be a lot of communications between her and the team. During the initial phase, one of our more cranky engineers was assigned to complete the project. Cara was new, we didn’t know anything about her. Mr. Cranky was in his heart a decent guy, but did not suffer idiots. Within two days, Mr. Cranky was complaining about Cara. We were not surprised about this, as Mr. Cranky complained a fair amount. About a week in, Mr. Cranky told his manager that he refused to work with her and demanded to be put on another project. No one in the development team was surprised.

Over the course of the next two months, it seemed as if the engineers were added to the project than left. After half of the engineers unsuccessfully tried to work with Cara, several of them got together for a beer in the kitchen one evening to discuss Cara. They decided that Cara had to go. Several of the senior engineers approach the VP of development and told him of the problems with Cara and that the team was refusing to work with her. The VP listened to the issues and told the engineers he would escalate it to the executives.

After the escalation, they tried using sales engineers for the project. The sales engineers were unable to work with her either. The project ended up failing.

Cara considered engineers as interchange widgets and that engineers were a cast of “untouchables”. Her disdain for engineering contributed to her failure, but was not the root case. The two main problems which made it impossible for her project to succeed were a lack of understanding and a refusal to communicate.

The problem was that Cara could not communicate the proper requirements to the team. She would communicate requirements which were completely in left field. The requirements were obviously not something any customer would want. Development asked her for clarifications, and she would shout buzzwords at the engineers then return to her office. The development team attempted to get direct access to the customer, but she refused to allow anyone other than herself talk to them.

Cara was a one trick technical pony, she only understood one technical item, and mapped every problem into the one thing she understood. Cara joined our company and was placed on the project immediately. Her previous two companies were in the same domain, with those previous projects all using the one particular technology to solve the problem. Unfortunately, this time the problem (and the solution) were different. Cara didn’t understand the problem the customer was trying to solve, which doomed the project to failure. She could no longer keep spewing buzzwords at the team and get them to build the solution. Cara refused to seek help for herself (or the company) by allowing another person to communicate with the customer, which further contributed to the failure.


This post started out as a discussion on the common enemy, Ted.  Ted is the guy who everyone hates in the office and wonders why he is still there (If Ted is your CEO, it is time to look for a new job).  As I thought about the Teds of the world, the theme of perspective kept coming up.

One of my Teds would constantly distract us from our work, arguing the peculiar aspects of a specification interpretation.  We had no problems discussing these issues in six months, but while we were trying to fix data corruption bugs, a bit of perspective was required.  I had to constantly recalibrate him. One incident occurred during crunch time in the early versions of the product. “Damn it Ted, it doesn’t matter how we interpret this esoteric section of the spec because it is meaningless until our users can load the work they just saved!  We have been working crazy hours for the past weeks trying to fix the load bug so that there would be a company in six months.”

It is important when you are deep inside a complex issue, that you do not lose perspective. Many good engineers have lost hours on less important issues trying to work them out to completion. Always remember that It is important to keep the end user user in mind, asking yourself if this is the best way to move the product forward for them.

Release Notes

Software is never releases, it escapes. Usually when it escapes, it comes attached with a listing of caveats and other information for the user which are listed in release notes.

There is a big difference in the internal defect description and the external description. For instance, internally a bug may have the summary, “XML Parser occasionally dies horrible death when comment field improperly terminated”. The external release note could be, “The XML input functionality requires that the XML is well formed. Usage of poorly formed XML may result in termination of the application.”

The selection of content for release notes is defined by the culture of the organization and the relationship with the customer.  I have been involved with the two extremes of release noting, where at one end we documented almost nothing, and the other we listed everything.  When choosing your philosophy, keep in mind the following:

Release Notes Leak

Each release note you write will end up in the hands of the sales force of the competition. Your competition will lie about your product, this just gives them more ammunition to confuse the customer and increase the duration of the sales cycle.

Release Note Visibility

You need to know who has access to the release notes. Some release notes are published on the internet, while others are hidden inside of the product installer. If the release notes are visible to those who have not purchased the product, it may be time to get marketing involved in their creation as the notes could affect product demand. If the release notes are only visible to those who have purchased the product, you can be much more open.

Does the customer care about this issue?

Yes, it is an important question to ask. Often dev will flag an issue for release noting because they think it is very important, but often they do not consider the program usage by the average user. I know that the program will crash if the XML being imported does not have the comment terminated, but I think it is safe to not release note this since the XML being imported is almost never edited by user. Development means well be asking for the release note, but after they have spent so much time working inside of the program, they often lose perspective.

What happens if we don’t release note this?

There are consequences for customers finding bugs on their own. It is usually better for the customer to be provided advance notice of the issues so that they can plan their work flows around the defects.

Will documenting this issue kill our chances of winning the product evaluation?

This is the one I hate the most. You should be proud of the product and acknowledge its short comings. The customer will find them out sooner or later. You will look more professional in the long run if you tell them the issues ahead of time rather than them finding them out themselves.

In one organization, I was specifically told not to mention any defects in the release notes because we were in the middle of product evaluations. This fostered a sense of mis-trust with the evaluators, who would constantly call and complain to me about the quality of the product. I finally convinced the organization to change their philosophy. Once we started producing real release notes containing useful information, their perception of our product quality by the evaluators actually went up. Before knowing the all the defects, they thought that almost all areas of the program were unstable. By telling them specifically what the supported scenarios were, it helped create trust and converted them from an evaluator to customer.

Does this make the company and product look really bad?

If it makes the company look bad and the product bad, it is time to consider changing it from the “Non-Gating, Release Note” to “Gating”.

Can this be explained concisely?

Why can the issue note be explained concisely? Perhaps it is to obscure of an issue to release note.

When in doubt, more is less. By trusting in your customers, they will trust in you.

A sample release note template is contained in the template section.

Formal Bug Triage

The formal triage is when we get the usual suspects together to triage the bugs.  These usually occur on regular interval during the main product release cycle and more frequently when we near a product release.  It is important to have a set recurring meeting for the triage because it helps ensure that the meeting happens.  There is nothing more demoralizing than entering a triage with a backlog 512 un-triaged issues because the triage has not happened for a while.

I have found for an effective bug triage you need Development, Quality Assurance, and Product Management roles filled in the room.

Development is there to help explain the impact of the bug.  They are also provide push back for items which will take a long time, and often argue for including items which are very quick fixes.  Development should discuss the risks and impact (including testing) of fixing the issue.

Quality Assurance represents the person who found the bug.  They are there to provide information on the severity and context of the bug.

The Product Manager is the owner of the triage.  They are the advocate for the customer and own the product.  The final decision of severity, priority, and milestone is theirs.

In a good triage group, there will be health lively discussion between quality assurance and development over each bug.  I love a good lively short debate on the important bugs.  Development arguing that the bug is a trivial edge case, with Quality Assurance saying that it is the end of the world.  Product management listens to the case for each bug, and makes the ultimate decision based on the customer’s needs, corporate delivery schedule, and product road map.

The triage room needs to have a projector to display the bug database and access to the latest build.  It is usually good to do this in a room close to the Development and Quality Assurance team since it will allow you to easily grab a developer when they are needed to help explain a bug.

When triaging a bug, you need to ask yourself several questions (which are in no particular order) for each bug. The result of the answers to each of these questions will help you determine the priority, severity, and milestone for the issue.

  • Will the customer ever find this issue?
  • How often will a customer come across it?
  • What is the impact of fixing (or not fixing) it?
  • Are there political reasons for fixing (or not fixing) it?
  • Does this bug block a customer demo scenario?
  • Does this bug make the demos look bad?
  • Is this bug a result of a real world user scenario?
  • If a customer found this, would we need to immediately spin a hot fix?
  • Is this a crazy bug which is only found under unrealistic QA environments?
  • If we do not fix this now, what will be the impact on future releases?
  • What is the impact to the current schedule of fixing it now?
  • What is the schedule impact of fixing it in the future?

There are several people who should not be in the triage room.  If a person has never run a development build, odds are they should not be included in the triage meeting request.  Never let marketing, finance, or any CxO into the room.  It will kill your ability to quickly go through the bugs.

Next Page »