Build a data structure optimized for how you know you are going to use it.
- how is it keyed, how are you going to access it?
- if you don’t know the best way to design it, start with a sub-optimal solution until you write more code.
- sub-optimal often means a group of lists or dictionaries of primitive types which operate in synch. Then you will eventually see that you need one two or more classes to keep the primitives in and refactor optimally based on your needs.
Build things at least twice, preferably three times
- the first time to understand the requirements.
- the second time to figure out the best design.
- the third time to do the implementation.
If you build things in a generic way so that they can be unit tested, they some of the things you build will be reusable in the second and third iterations.
Draw ERD’s to understand the database
An entity relationship diagram is a diagram showing how tables in a relational database relate. The boxes are the tables and the line between them are the relations. ERDs are like having a map to learn how to get around a city.
- use crows feet for the relations.
- ignore types but include each column name, key name and table name.
- make the table boxes 2 inches (or 5 cm) wide.
Draw ‘calling’ trees to understand a large code base
They are like having a map to learn how to get around a city.
- draw it so that the callers are on the left and the called methods are on the right.
- use arrows to indicate non-direct calls (like event invocations, web service calls etc.).
- the step through debugger is your friend in this.
Estimate a project at 4 x (new db columns + new db tables + information characteristics + relevant target fields) hours
- I just did a project with 22 columns in 4 tables, 12 characteristics, and 22 target fields in about 260 hours.
- the phases were 1) prototypes and requirements(10days), 2) design document(1day), 3) convert to production quality code (5days), 4) finish production code(10days), 5) convert to using web services(4days), 6) testing(1day), 7) deployment(1day) ~= 260 hours.
- make the estimate 5 x instead of 4 x for a kind of program you have not written before.
- If you do not get the project done within the estimated time, bump that factor of 4x or 5x up to what it needs to be for your experience level for succeeding projects.
Useful items to have in documents are:
- WHY. why the customer need this and how they will use it
- REQS. requirements.
- OODD. object oriented design.
- INFO. information analysis and design.
- UISD. User interface layouts and story boards.
- RDB. relational database design.
- NETS. networking and integration needs.
Depending on the size of the project these could be in one or multiple documents. Here is how these items relate:
OODD--REQS / \ / \ RDB--INFO--WHY \ / \ / NETW--UISB