Why Don’t Organizations Use Their Own Defect-Tracking Systems?

Picture this: you’re working on a critical application for your company, used by countless people around the world. This morning, as the new update rolls out, a user in Detroit pushes the main button on your app — and nothing. Your app hangs. Something went wrong. Now nobody can use your app.

Now picture this: you walk into a new team. You’re the person who knows WhizzBang 7.0, and the team desperately needs your help. The new update is failing! You grab a seat and ask for a working computer.

But they can’t give you a working computer. Security policy says only the person assigned to each computer is allowed to use it. So you ask for your own computer. But that’s going to take a couple of days to sort out — the infrastructure staff is slammed right now with customer complaints from some kind of app deployment problem. You ask if it’s possible to get a new login on an existing computer. It’s possible, but usually takes a few hours. So then you ask if somebody could code on their computer while you tell them what to do. That works, but it’s technically against policy. Pair-programming has not been approved yet for all dev teams.

Both of these situations involve defects. The first defect is about a deployed product. People are expecting value from your product and are only finding frustration. Everybody’s familiar with that one. The second defect is about a broken organization. The people who make things happen in your organization are expecting to keep creating value and grow your business…but they are only finding frustration.

Why Don’t Organizations Use Their Own Defect-Tracking Systems?

I can only come up with three reasons:

Why are defect-tracking systems only good for the users and not ourselves? Isn’t it much more important to make sure the organization is running well? Doesn’t fixing that prevent a lot of the defects that our users end up finding downstream? Isn’t it much more important to fix and optimize the machine that makes stuff people want instead of constantly playing whack-a-mole with bad stuff its made?

Hi, I’m Daniel Markham. I wrote a book called Info-Ops that talks about how to have conversations and organize what we’re doing so that we build the right thing without a lot of the usual BS. As it turns out, looking at what we do from an information standpoint tells us a lot more than simply talking about what activities people do every day or how various tools are configured or used.

Follow the author on Twitter

May 28, 2018

Leave a Reply

Your email address will not be published. Required fields are marked *