Sunday, March 30, 2008

Good Design Vs Good Coding

Do you do the design document before or after the coding cycle? Logically everyone would say that you have to do it before the coding cycle but the fact of the matter is that many people do it after the coding cycle. They finish the code and then feed the code into a tool that will draw a design diagram for them based on the code that was submitted to it. They then take that design diagram and write the design document based on that diagram.

Now if we compare this to the real world it would be like constructing your house by a bunch of brilliant architects each having his own idea of what he wants to do with the house and after each one of them says they are done you draw up the design based on what you see. Can you imagine what you would get? Thats exactly what happens in the software that is designed after it is built its just that everything is virtual and it is not as apparent as it is in a building but its pretty much the same. Hence having brilliant programmers does not help to come up with brilliant software if it does not have a brilliant design that is guiding them.

What are the reasons many of us do not design before we code? Some of them are
  • It is hard to design because software is an art and each task varies so you do not know how to do it till you start doing it.
  • What do i design? I know what I am going to build why waste time putting it down on paper.
  • Design is to be done only if you are going to hand over the coding to junior developers who do not have the experience to code something like this.
  • A design document is only to explain the system to the people maintaining the software it is not for us to do development.

I am sure there are many more reasons but let me now tell you why you need to have a good design

  • A good design is the glue that keeps the vision of all the brilliant developers in the same direction. It is the guiding force the leads them to where they want to take their brilliant product to.
  • It gives a consistency to what is being developed so that it can be maintained easily.
  • It identifies the flaws and the areas that can be potential bottlenecks early on so it can help the planners make more realistic plans.
  • You can validate a design with a third party before anything is built thus saving a lot of time.
  • It has been proven that with good design the amount of time spent coding and bug fixing comes down significantly.
  • With a good design document there is something to validate the code against while testing.

Let me now give you some of my answers to the reasons given by developers as to why they do design after development

  • If there are unknowns while doing the design create prototypes of what is to be developed. These are scaled down models of the actual stuff that will proove that the idea is implementable. It is like an architect building models of the house to show you what you are going to get. Architects also make scaled down models to prove some of the new designs.
  • The "cookie cutter" approach can be used and a sample of the replicable portions of the application can be developed. Architects do a sample house or a sample apartment in a building as a way to prove that the rest of the houses or apartments will look like this.

Design does take time and patience and there are times it gets stalled with little or no progress. You must be careful not to over architect the solution. There should be a moderator while doing design that always ensures that progress is being made and if there is a potential bottleneck that can delay the project necessary action should be taken to come up with alternative solutions or to consult outside experts. But think of it this way it is better to know of these problems in design rather than in coding.

On the whole good design gives you a lot of efficiencies in the other phases and it is a phase that should not be bypassed however experienced or competent one is.

No comments: