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! (written 2009-12-02, updated 2009-12-09)
Associated topics are indexed as below, or enter http://melksh.am/nnnn for individual articlesQ907 - Object Orientation and General technical topics - Object Orientation: Design Techniques 
Associative objects - one object within another. - (2016-01-20) 
Spike solution, refactoring into encapsulated object methods - good design practise - (2015-03-05) 
The spirit of Java - delegating to classes - (2015-02-18) 
Test driven development, and class design, from first principles (using C++) - (2014-12-30) 
Using object orientation for non-physical objects - (2013-05-22) 
Teaching OO - how to avoid lots of window switching early on - (2013-01-17) 
Storing your intermediate data - what format should you you choose? - (2012-11-20) 
Inheritance, Composition and Associated objects - when to use which - Python example - (2012-10-10) 
From Structured to Object Oriented Programming. - (2012-10-02) 
Rooms ready for guests - each time, every time, thanks to good system design - (2012-08-20) 
When you should use Object Orientation even in a short program - Python example - (2012-07-06) 
Spike solutions and refactoring - a Python example - (2012-06-13) 
Why you should use objects even for short data manipulation programs in Ruby - (2012-06-10) 
Designing your application - using UML techniques - (2012-02-11) 
Your PHP website - how to factor and refactor to reduce growing pains - (2011-09-24) 
Ruby - a training example that puts many language elements together to demonstrate the whole - (2011-04-23) 
Object Oriented Programming for Structured Programmers - conversion training - (2010-12-14) 
Comments in and on Perl - a case for extreme OO programming - (2010-11-21) 
What is a factory method and why use one? - Example in Ruby - (2010-09-30) 
Turning an exercise into the real thing with extreme programming - (2010-09-11) 
Should Python classes each be in their own file? - (2010-07-27) 
Program for reliability and efficiency - do not duplicate, but rather share and re-use - (2010-07-19) 
Relationships between Java classes - inheritance, packaging and others - (2010-07-10) 
The Light bulb moment when people see how Object Orientation works in real use - (2010-05-28) 
Containment, Associative Objects, Inheritance, packages and modules - (2010-04-30) 
What is a factory? - (2010-04-26) 
The Multiple Inheritance Conundrum, interfaces and mixins - (2010-04-11) 
Simples - (2009-11-12) 
Object Oriented programming - a practical design example - (2009-08-27) 
Planning! - (2009-08-08) 
Designing a heirarcy of classes - getting inheritance right - (2009-05-11) 
When should I use OO techniques? - (2009-05-11) 
Teaching Object Oriented Java with Students and Ice Cream - (2008-02-12) 
Object Oriented Tcl - (2008-02-02) 
Object Oriented Programming in Perl - Course - (2007-11-18) 
Object Relation Mapping (ORM) - (2007-06-09) 
What are factory and singleton classes? - (2007-06-04) 
Maintainable code - some positive advice - (2007-01-21) 
Build on what you already have with OO - (2006-08-17) 
Comparison of Object Oriented Philosophy - Python, Java, C++, Perl - (2006-08-13) 
The Fag Packet Design Methodology - (2006-06-06) 
Think about your design even if you don't use full UML - (2006-03-24) 
Design - one name, one action - (2005-12-19) 
Introduction to Object Oriented Programming - (2005-11-27) 
Tapping in on resources - (2005-03-05) 
OO - real benefits - (2004-10-09)Y116 - Python - Applying OO design techniques and best practise 
Defining an object that is a modified standard type in Python - (2016-11-02) 
How to avoid too many recalculations within an object - (2014-12-21) 
We not only teach PHP and Python - we teach good PHP and Python Practice! - (2013-06-18) 
Really Simple Class and Inheritance example in Python - (2013-03-04) 
Tips for writing a test program (Ruby / Python / Java) - (2010-01-29) 
How do I set up a constant in Python? - (2009-10-31) 
Testing code in Python - doctest, unittest and others - (2009-09-16) 
Alpaca Case or Camel Case - (2009-08-16) 
Good Programming practise - where to initialise variables - (2007-05-09) 
Code quality counts - (2006-11-26) 
Python - block insets help with documentation - (2006-04-04) 
Code and code maintainance efficiency - (2005-06-08)
Some other Articles
Flying tonightA reluctance to move from old shoes to newUsing JSPs, Tag Libraries, Java Beans, Tomcat in one short exampleAn update on legal changes from the FSB?Plan your application before you startIntegrated public Transport - what could be done for MelkshamMelksham Market - Tuesdays, 09:00 to 14:00Global and Enable - two misused words!Status Page / breaks of service in early DecemberThrough the arches