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