In my current work environment it seems as if I spend way more time pushing out code than spending time making sure the quality of the code is good. Quality in this context means that you actually spend some time before you code planning the structure of the program you are about to create. In its simplest terms this is simply penciling some ideas down and drawing a few basic flowcharts. Doing this enables you to see things unfold a bit clearer, because I have found myself in a situation where I started coding and I got to a stage where the logic of the code went sour and it meant recoding everything or parts of it. With a bit of planning and design beforehand this can be avoided.
On a deeper, more complicated level, detailed specification building that incorporates requirements definitions and the full SDLC type-of-thing, obviously provides a different approach. But I think when you get to a deep and complex level you are addressing a big group of developers. Or can the same principles be applied to smaller projects?
I do find that I draw a lot of contextual diagrams in my current work, because I like having a contextual overview of what I am doing and what the system I am busy with attempts to achieve. A contextual diagram is usually a very basic diagram that just shows the system on a high level, with the idea being that you drill down to deeper detail from there. I remember using an analysis methodology called SSADM (Structured System Analysis and Design Methodology) and remember it as being very, very structured. You would start your diagram at the contextual level and drill down until the very lowest level. I do find OOAD (Object Oriented Analysis and Design) easier in a sense though, because you can directly translate objects in the real world to objects in the system. But I still draw contextual diagrams for OOAD.
The point though is that planning a piece of code is as important as the code itself and is a discipline.
