Most developers know the term DRY, don’t repeat yourself. To code monkeys, it is second nature. What’s funny is it can be applied to everything, not just coding. Most developers don’t get this.

Today, one of my team leads did a tech talk for his team. The talk was an intro to MVC, specific to their project. It was awesome. You might be thinking, MVC is second nature to me. I have been using MVC for years. Any noob should know what MVC is. That’s not true.

At Mailtrust, the vast majority of our developers come from the coolest school across the street, Virginia Tech. Many of them didn’t learn MVC in school. Even if they did, they have never used it in an enterprise environment working in a team.

Camtasia to the rescue. For this tech talk, we did our first screencast recording. Now we have a reusable, applicable, and awesome training tool. The next time someone asks what MVC is, they won’t get the 5 minute high level talk that leaves them more lost than before. They get an hour long presentation, with full demo and discussion. Sweet. No more repeat training sessions.

I was thinking about product backlogs today, and I realized that they represent an interesting paradigm. In short, they equate features to a checklist. Once it is done, it is marked off. Completed. Done. Finito.

In reality, this isn’t true at all. A feature is a commitment to your users. For every feature, the initial cost is usually design, development, testing, documentation, and support. What’s funny, is every single one of those is a continuing cost that usually gets overlooked. For every feature, there are bugs that developers need to fix, testers need to verify, and writers need to document. For every design, there is usability testing that reveals flaws. For every feature, there is support.

To succeed, I think there are really two choices. One, eliminate as much continuing cost from each feature as possible. This can be accomplished by reducing uncertainty. Unit tests, functional tests, usability tests, continuous integration, and multiple testing environments all reduce this uncertainty. Unfortunately, this slows your turnaround time down unless you can hire at a rate greater than your continuing cost, which is hard.

Or you can implement less features. This means every feature you implement has to be super important and you can spend a lot of time making it awesome. What’s funny is you now have time to do all the things necessary to build a feature with a very low continuing cost. The obvious downside is, you may not be able to compete because your competitor has everything you don’t.

What’s better? I honestly don’t know. What I do know is every feature should be thought of this way and not as a checklist item. Then skipping that useless unit or functional test doesn’t seem as appealing.