Design: 

step #1 of a project 

is the most important: 

Once the journey is mapped out and broadly agrees, Design can start. 

The system designer should uncover exactly what the minimum requirements are to fully achieve the objective, and then what is likely to be needed within a reasonable time scale (12 months).  To meet underlying system requirements, this often means using defaults and auto-fill functionality related to the individual user - and this approach must be identified and adopted across the system as a whole; ideally before the "heavy" system design is started.   

It is pointless to minimise database size, as there is little technical with even huge databases (e.g. 1Gb). 

However, it is sensible to minimise SQL joins, and trying to connect many data tables together - 

this often becomes a tangle, and a big maintenance problem.

Storage is cheap, and it is much more important that users are able download an entire table - 

- without a join (for personal, local analysis). 

Database technology has massively improved performance when using 400 fields: 

30 years ago, this was impossible - today, it is a benefit.

Design should be compartmentalised so that staged, progressive chunks of system are developed - and successfully implemented: one should avoid attempting to design & build an entire business model system ready for a "big bang". 

Change to system designs should be encouraged, before any coding starts.

Attempts to make changes during the coding stages, should be utterly avoided.

In testing, revisions and updates and amendments have to be tightly controlled. 

Many individuals see the catch phrase of "agility" as being critical - it is how we think. 

That is; rapidly changing, flexible, cross functional, self organising, end user and client focused.