Jody Hamilton has been doing Drupal development and leading Drupal teams for about ten years. She’s worked on a lot of rescue projects- fixing the messes that are created when another team skimps on quality. Ongoing quality assurance testing is an essential, yet overlooked aspect of software development and determines the viability and longevity of products. Today we present the first part of a series of posts on Quality in software development. This series is based on a talk Jody gave to entrepreneurs at Dreamit Ventures last month.

If you're not super focused on quality, you get a group of developers with their own personal standards. Nobody really examines what those personal standards are. Maybe some of them care about code quality, maybe some of them are into coding standards, maybe some of them use code commenting and care about how things are organized, but maybe some of the others don't.

Then you add time constraints from the CEO who wants the launch to be ready for a conference or event. When you apply constraints to your developers, there are two ways it can go. One is to say, "Okay, because this is coming up, we need to focus more on the demo and deprioritize other aspects for now." That's a healthy way to react to a time constraint. The other option is to say, "We have to meet this time constraint no matter what, so let’s just do it somehow." You apply stress and the only way they can react is to cut corners. "We're going to acquire a little bit of technical debt and pay it back later. There's going to be a mess, but we'll come back when we have more time and clean it up." But guess what? Tomorrow never comes.

Then, maybe down the road you lose the developers who wrote it in the first place. Now you've got some more developers, but they're not really in a position to fix it because they don't understand the mess in the first place. You get more debt.

Now it's taking longer and longer to develop on your platform. People are talking about a rewrite. They don't want to work on your software anymore because it's aggravating. You're going to have a hard time keeping the best developers and attracting good developers who aren't really interested in working on your big mess. The last step is total failure.

This is a really common scenario. People don't talk that much about how serious technical debt is because it's so bad that they don't even want to talk about it. We try to laugh it off with jokes. If you talk to people who have spent a couple of years on their startup, and if they're being honest, they'll admit to you, "Oh, yeah, we have a real problem with technical debt. We don't know what to do." That's a really common refrain. It's not just, "Oh, they got unlucky," or, "They had bad developers." This is the natural result of not being focused on quality throughout your process. It's not bad luck or an unusual reaction.

Continue to Part 2 of this series, The Difference Between Quality Assurance and Quality Control.

Terms:

• Tech
• Drupal Planet

Publishing Workflow

Ready for Publishing