Planning cuts time bug fixing

I was reading code complete and at the start it talks about finding bugs or problems earlier means you can fix them quicker. It is a basic introductory type chapter talking about why you should plan your code before you start working (coding) on it.

The chapter is based as an argument to help persuade your boss it's a good idea. He Steve C McConnell also has some very good sayings in his book, this chapter is "Measure twice, cut once".

The point is interesting because planning and not coding straight away would seem to managers or some programmers as not the fastest way to get the work done. Personally I have found that planning and thinking about the design of the code very useful mainly just because by thinking about the problem you can discard some ideas which initially might seem quite viable but once you investigate the work flow of the problem you can see it is flawed or not the best way. By doing a bit of planning and by this I mean some rough class or sequence diagrams maybe or just some scribbles on a piece of paper you are basically working on the problem but are not bogged down in code.

I have been involved in a few examples where the customer added in what seemed a small piece of functionality but because they didn't mention (or I didn't ask) earlier it meant adding the functionality in at a later date which can often be a lot harder and trickier than if the functionality had been in the original spec.

In some ways I think it is a bit similar to writing unit tests before. Writing unit tests basically makes you decouple the functioning parts of the program and test them to make sure they work and then when you are happy the small sections work you can change the design and navigation code which brings them all together safe in the knowledge that the small parts are working correctly.

I think the point of chapter is that fixing a problem earlier means that there is less code or less of a system/protocol which you will have to change to fix it. Fixing bugs when you have finished all the coding can often mean that you have a choice of either doing a major refactor or wedging in a "dirty fix" around the existing infrastructure and code. I maybe going a bit over the top with all this dirty fix nonsense but bug fixes are often added on to the existing code and if a few fixes are added in (often not by the person who coded the original) then the code will start to become messy and smelly.

In my experience the code in which I have thought about the design in a more detail has almost always been more robust with less bugs so I would say that it is a good point.