Thinking about process

I’ve often heard (and probably said on at least one occasion) words like “We don’t have time for code review” or “The deadline is just too short to for unit tests.” These are words that run directly against meeting deadlines. Sure, it’s possible to meet deadlines without continuous integration, unit tests, code review, or any other quality assurance mechanism. But what is the cost? Over time, bugs will creep into the code. Bugs that might not be found until code is in production. Bugs that might be, potentially, very time consuming to fix. The initial cost of setting up continuous integration, of doing test first (or test driven) development, of weekly code reviews comes out to be much less than the cost of plowing headfirst into development efforts and fixing bugs later, when they’re found. Defensive programming practices are, ultimately, agile practices. They force us to think about what we’re doing. By following process and thinking clearly about the choices we make when we’re developing our code we can ensure that the final product is largely free of defects and can be easily maintained and repaired when a defect is found.