Archive - Originally posted on "The Horse's Mouth" - 2009-12-02 22:51:51 - Graham Ellis
Planning your project / application ahead of time can save you so much heartache and wasted time that it's untrue - but there is still a tendency for people to jump right into to coding without thinking "how will this work". And you should think "How will this work" in many ways.
These seven diagram types owe more than a passing resemblance to UML (Unified Modelling Language) where every system is described as a model ... but I have not (and do not) attempt to produce full sets of drawings with all the correct box shapes for the sort of simple systems we work with. However, it is extremely useful to be able to think through things to the extent that you would be ABLE to produce the diagrams - or an overview of them - if asked.
What diagrams do we have?
1. Diagrams showing what the various data sets are, and which person / people / roll produces and uses them
2. Diagrams showing each of the classes of object that we use, with a heirarcy of what inherits from what, where the abstract classes lie, where the methods are defined and over-ridden
3. Diagrams showing each type of object - what variables it contains, including other objects, and how many of each it contains.
4. Diagrams showing how objects are created, modified as they pass through the system, and eventually destroyed
5. Diagrams showing the life of software through from source and download distribution through compiled versions, version control systems, testing and live servers right through to the backups that the whole system could be restored from
6. Diagrams showing how transactions work - where user input is made, which computer(s) are contacted with what traffic through which protocols.
7. Diagrams that show the detail of how code sections work.
I was asked, last week, what order I would produce these diagrams in / think through my design, and that's marked on the white-board picture at the top too. In practice, they'll tend to be developed in parallel - broad brush strokes and important key design first, then more detail. However - in general terms: 1, 4, 6, 3, 2, more 4, 7, 5. In other words ...
a) Why are we doing this?
b) How will it look to the user?
c) How will it run - what elements where?
d) What is the object structure?
e) What is the code detail?
f) How will the development, deployment and backup systems work?
If you can have an idea of the answers to these questions before you start too much detailed coding (though you may try a few 'spike solutions' for your algorithms) they you will save yourself a lot of blind alleys and you'll probably come out with a good, well-rounded system!
Planning your project / application ahead of time can save you so much heartache and wasted time that it's untrue - but there is still a tendency for people to jump right into to coding without thinking "how will this work". And you should think "How will this work" in many ways.