It really shouldn’t be a surprise, but I have recently witnessed firsthand how a little bad code sprinkled here-and-there quickly adds up to a lot of BAD code that’s painful to work with.  That’s the scenario we’re facing now with our ASP.NET MVC application.  Our team conducts peer reviews for every bug/feature, but we’ve still built up a small mountain of technical debt that we’re going to have to pay sooner or later.  Our once-clean code base has become complex and difficult to work with.  Even simple changes are starting to take progressively longer to implement. 

How did this happen?  There are probably several reasons, but I think one cause is that we’re still too lax in our peer reviews.  If we don’t see something that’s HOLY CRAP THAT’S BAD, we let it slide, even if we don’t really like the solution.   At least, I think that’s how I’m contributing to the problem.  Starting today though, I’m going to resolve to be a lot more strict on my reviews.  If something doesn’t feel right, even if I can’t put my finger on it immediately, I’m going to spend the time to find a better solution.  The alternative is what we’ve done: start with good code, then progressively keep adding a little bad code here and there until we’ve ended up with a big heaping mess of poorlyuctured code.