Archive - Originally posted on "The Horse's Mouth" - 2009-08-08 08:46:17 - Graham Ellis
When I travelled from home to Saudi Arabia in May, 2006, I planned ahead. Flights were booked, course manuals printed, Visa obtained, contacts established, deposit paid (to us for courses), travel insurance in place before I even left home. "Of Course" or "Prudent", I expect you'll say. And I agree with you.
So why is it that when people start on a major software project, they're tempted to jump in and start writing code from an early point? Shouldn't there be a great deal of planning done before the first programming - checks that what they want to achieve is fully understood, and that it will work and there will be few hidden surprises? Well - it's a very brave analyst / programmer who, half way through a six week project, hasn't written a line of code ;-). But is CAN work.
I recall the "Bill of Materials" module of our "Designer I" CAD product (written by myself, David, Julie and Adam in the 1980s in Fortran, C and Assembler, running on PCs, Linux, Sintran, RSX11M ...) which was specified down to the extent of the user manual being complete before a line of code was written. An excellent module, which did what is said on the box, and worked well for our customers. Th eonly problem I recall was that - having put the manual into the hands of our sales person - we also had orders (and with an impossible tight timescale promised) before any code was in place.
I was reminded of this yesterday, when I was helping with the design of a new project for one of our friends and customers, and although the project will be in PHP, we didn't write a line of PHP all day.
We started off with "Use Case" - looking at what the data held by the system will be, who provides it, who uses it. We extended "use case" somewhat by adding in weights to the various users, both in terms of how much traffic each role will generate, and how sensitive that role is to a 'good' or 'bad' system - the user profile.
Alongside "Use Case", we thought of key features and extensions, looking to think well ahead at an early stage of what the system must do at day 1, what would be really helpful in terms of extra features that will help it be accepted / used / strongly taken up from day 1, what will help make it usable, secure, extensible, manageable and profitable. In my own mind (though not, I will admit, on the paper), I was thinking through how each user will walk through the system - "State Diagrams", and at lunch we talked though with a potential user of such a system about what when would like to see in it / how it could work for her. That's an unscientifically small sample size, I know - but never the less, a first sanity check to say "have we overlooked anything serious here?".
Towards the end of the day, we moved on to a more detailed look at the data to beheld - the structure of the tables. And, in this case, we chose to write the description down in the form of MySQL CREATE TABLE commands, to see how it would work, together with some INSERT commands to actually add data in to the tables. We preceded these commands with a DROP DATABASE and a CREATE DATABASE so that we could try it out, time and again, and we added in a handful of SELECTs so that we can see how - when code is eventually written - the data will be accessed. The file (as it was by the end of the day) is here.
With a solid, tested, thought ahead design for the database, this system can be a big success. Design issues considered / resolved very early include:
a) The main tables, and how they are normalised to avoid data duplication, to avoid multiple values in a single field, and to avoid the storage of calculated results.
b) Table and field names based on a consistent convention so that coding will not be held back by "what did we call that field" or confusion between multiple fields of the same name.
c) Deciding the data types for the central fields early on, and allowing for additional fields to be added easily into each table, preferably getting most of them specified and 'in' early on.
Although each table has an auto_increment id field, we specified record IDs manually in our test data, using a different range of integers for each of the id sets. Thus, the categories of course are numbered from 200 upwards, individual courses from 300 upwards. This is purely for early 'Spike solution' testing so that we can easily see and work through the database logic; come the live system, they'll all start automatically at 1.
I hope to be able to bring you updates on this project from time to time, and perhaps to be a consumer myself in the (not too distant) future - I know it is something I would use if easily available here in Melksham. And it's good to be reminded that the chapter in our Perl Programming Course that's headed "Design Matters" is actually capitalised / styled as "Design MATTERS" - in other words, remember the importance of getting the specification right to begin with!