How much Designing should be done before coding?

I have been planning and designing this week. I am not always sure how much planning to do, except that I know you should definitely do some. There is a lot of talk about UML and planning and drawing big uml diagrams. I have mixed feelings about uml diagrams in some ways I just think they are a fancy way to label the rough sketches you do on your pad.

The main benefit I suppose is that if you use a standard notation then you will be able to show and discuss your uml diagrams with other developers and they won't have to learn you own individual modelling/sketching style. Asking other developers to have a look at your design is often a good idea because they can view the design from a different perspective to you.

I often like to use a mixture of things to start with, I often like to write down the flow of event in text. This is basically a text version of the sequence diagram. I find that writing it out can be quicker and less fiddly than drawing a sequence diagram. Then the more I understand the problem the more I can lump things into broad categories and from here I can drill down towards some rough classes. So I basically try and work down using packages and then rough classes and then try work out how they would interact with each other. When I am thinking about the interaction between packages and classes this is when I start to think about rough interfaces to capture what is being passed about and to what classes.

I view planning as trying to build a three dimensional cube. If you only plan and design the project quickly you will only draw one side of the solution. By planning and designing by drawing some uml diagrams, writing notes, basic sketches, you are looking at the same problem from different angles and inspecting the problem more thoroughly. This allows you to work on solutions from other problems you find.

You can't always spend that much time on the design, even though you probably should but in the real world some times we are pressured to get started and write some code (even though it could be wrong if you haven't spent enough time designing your plan of attack). If this is a situation you find yourself in then the best way to go about this is to make sure you have split up the various sections of code using interfaces and loose coupling. Then if you find that one part of the code has to be changed then you are minimising the dependencies on that code and you will be able to change it behind the interface without effecting the other code.

Another good tip is to get some skeleton code up and running and getting everything connected and compiling even if it is only returning hard coded values. This will give you a good idea of the work flow and whether it is going to work, you might find that you need some additional variables for certain bits of the code.

This method also allows you to hard code sections of the code so it can be tested earlier

Basically I don't think it really matters how you do your designing but the benefit of UML diagrams is they can be easily understood by other developers and you can store them away (especially if done on the computer) and then when you or someone else has to do some work on the project 6 months on, you can look at the diagrams and written notes and get an idea of how the code works, which can save you lots of time.

My usual tip for planning is to do enough so that I am just starting to get bored of it, that's a good sign I have done enough.

Don't forget the new edition of Amusing IT Stories is out this friday, so if you like amusing IT Stories don't forget to check it and you can read the first edition on the site currently.