Quality Assurance icon

Always app test

Even plain old code is more than just code, if you’re going to succeed in the market. Your commercial application has to work once it’s out in the wild and users start putting it through its paces. A product that doesn’t work isn’t a product; it’s a liability.
There are two ways to build security and quality assurance into a product: at the end, or as you go. At the end is costly and discouraging, and even product-killing. Finding out two weeks before launch that there’s a major flaw, that the product simply can’t do something it should do, or that it has a major security vulnerability, is a development and business nightmare. So we test and secure as we go.

Consider these

  • Give your developers more information than they need

  • Stay open and available

  • Have developers haunt the code

How we avoid ugly surprises

How we avoid ugly surprises

We make sure we give our developers more information than they need

Our project leaders will walk into people’s offices unprompted and give them an information dump. They’ll say, “I know you’ve got this one task to do, but let me explain to you why you’re doing it and what it means in the larger context—not just what you have to do.” It’s part of our culture. We do that a lot with changes, too. We might tell the team, “Just so you know, we just made this decision over there, and you should be aware of it. You don’t need it now, but you might need it in the future at some point. So just be conscious of it.”

We stay open and available

At AVI, we’re very open and inviting. Our manager’s offices are sometimes like Grand Central Station where people just walk in and ask questions on the fly. It fosters collaboration and communication, and it helps everyone to know what everyone else is doing and wrestling with. When your engineers are connected like that, they can make better-informed decisions during development. It takes a lot of energy to maintain this kind of openness and availability, but it works. And it’s a lot easier if you’re a small company.

We haunt the code

Sometimes our managers check out the codebase at 2:00 a.m., just to review the code. That way they can ask the developer questions like, “Why did you do it this way? What happens if you do this or that? If such-and-such happens down the road, how do you think this could be done better now, so it’s much easier later on?” Because we do that (but not too much–we don’t want to be annoying), engineers start asking those questions on their own. They’ll say to themselves, “If I just make this a little more generic, I get the feeling it might be useful down the road.”