Personal Opinion: Bug Prevention Techniques Bugs are a normal part of our lives as software developers. Here are a couple of suggestions to help you prevent bugs. For starters, there is no substitute for printing out your own code and walking through it on paper, away from the computer. This is perhaps one of most effective practices, but requires a bit of patience. Many organizations take this one step further by doing code walkthroughs. Extreme Programming handles this via its pair programming. Another good option is to walk through your code using a GUI debugger. You don't have to use a debugger just for debugging; you can also use it to verify that your code is working as you expect it to. However, in my opinion, one of the best ways to reduce bugs is by developing software in smaller chunks. In other words, for each iteration, two weeks in length, we have minimal requirements up front in the form of high-level and low-level requirements. For the high-level requirements, you could do some initial UI sketches (for a user interface application), domain modeling, user stories, and so on. These are typically done at the beginning of a release. At the beginning of each iteration, you get detailed requirements in the form of acceptance tests. Given this approach, there is a lot less that can go wrong. Furthermore, when you factor in the test-first approach (recall the "Writing Unit Test and Actual Code in Same Sitting" sidebar from Chapter 7, "The Spring Web MVC Framework") combined with refactoring as and when needed, your code is bound to be more solid at the end. Iterative development using short and fixed cycles (two fixed-week iterations, for example) combined with active stakeholder participation can help reduce some of the pressures of time-sensitive software delivery; this is possible because the customer sees progress on a regular basis and is likely to be more flexible and understanding when it comes time for missed deliverables. This reduction of time-sensitive pressure can also help you write more stable code and not just something you throw over the wall, so to speak. Finding bugs is no fun. I sometimes feel like it is similar to looking for a real-life tiny bug that is hiding in a big room filled with lots of stuff. By doing true iterative development (from requirements through deployment) and having smaller-size fixed-iteration lengths (two weeks being ideal), you are likely to prevent bugs and enjoy coding a lot more! |