This is part 4 of a series based on Jody Hamilton's talk at Dreamit Ventures to a group of entrepreneurs. Check out the other pieces in the series including The Heartbreak of Technical Debt and Good For the Code & Good For the Coder.

It happens all the time. You pester your developers to get more serious about quality, adding comments, and making it easier for people to understand what their code does so others can work on and maintain it. They may say they will do it. But they don't really care. They're going to be gone in a couple of years.

Most of the code running things in the world is really old. Banks are running on code from the eighties. It's one of the biggest problems of our era, this unmaintainable code.

It's actually fairly easy to make your code maintainable. You just have to be concerned about maintainability the whole time you're writing. It might take you ten percent longer from the beginning, but if you don't do it at the beginning, you end up with a very high interest debt. It gets to the point where you will never be able to dig out of it.

Even though you might have to use ten percent more time focusing on quality, you can double down on how you're using that time if you realize that it's for professional development as well. When I am reviewing someone's work and there's some little thing that I think could improve, I could change it really fast to be efficient. Instead, I give the work back to the person who wrote it and say, "Hey, this is what you need to change." The bigger point is for them to learn how to do things in a more maintainable way.

Code will become better and more maintainable, not just through your review and sending things back, but due to the fact that people know someone is going to review it. It is going to change the way that they're writing it in the first place.

How do you actually get more serious about quality? You must have explicit standards. There are coding standards out there. For example, we follow the Drupal coding standards and that governs things as small as where we put our spaces. It sends a message to the developers that every little detail matters. This is something that's very serious and we're going to take it seriously down to the space bar.

You need to have standards for code comments. How much is too much in a code comment? Do they begin with a capital letter and end in a period? Do we need to have one for every function? How are you going to organize your code? These are standards that should be evolving. You should try constantly to up your game with more and more standards and have the whole team on the same page: as a group, we're going to constantly try to have better and more standards and be on the same page.

You also need to have a culture where people can take criticism and it’s normal that people are critiquing every little thing. Instead of defending and saying, "That doesn't matter. It's just a space. Get off my case. I have things to do." You have to say, "Okay, yeah, you're right. That is a valid way I could improve, so I'll just take care of that."

The most important thing about quality is that the founders and the top people in the organization are committed to it. If you have a CEO who doesn't care about quality and then every once in a while he or she comes in and says, "I don't care. Get it done. I have a deadline. I don't want to hear it. Make it happen." There goes all your quality. Because that one time when he came in, or she came in, and freaked out about the deadline, and didn't care about anything but that, is when everything got messed up. Nobody cared about the quality anymore.

You're going to need to build in time for QA. You can't just say, "We're going to develop up until the launch date." You're going to have to allow time to test, to refactor, to clean up, and to improve. Make that a positive thing.

Terms:

• Drupal
• QA
• standards
• Drupal Planet
• code review

Publishing Workflow

Ready for Publishing