The first lesson that an IT consultant learns when helping sort out a problem with a database is to never volunteer any opinion of the strategy of the development. Your job is to just get them over the hurdle even if they are running in the wrong direction. Those words ‘you shouldn’t be doing it that way, you should be …’ have to be caught in the throat however irresistible the giving of the advice. Sure, you are occasionally asked how the development got into such as sorry state and you can then brightly point out all the catalogue of errors in the development work, but in my experience, mostly heroics are required of consultants, rarely wisdom.

The problem is, of course, that if you’ve lost your way, and you don’t realize it for a long while, you don’t like being told to go back and start again. Sometimes, in development work, there is a team decision that is entirely wrong. All that an individual team member can do is to remind the others occasionally that the ridiculous problems they are having are due to this original fatuous design decision that it is now too late to correct. If a consultant wades in brightly and points out the absurdity of that bit of design, feelings can run high. It is often a bad idea to give advice to someone who is powerless to change a development design decision despite knowing full well that it is wrong. They generally just want the quick fix.

This powerlessness comes from the vast quantity of code and effort that would have to be scrapped. The problem should have been spotted earlier.

I’ve always maintained that one of the killer advantages of frequent database builds as soon as possible in development, and maybe even continuous integration, is that it flushes out many design problems. It is not just the comfort of being certain that the whole team is working on the same database and that what is in source control really represents the database, but it brings to light many of the symptoms of poor database design.  It is more difficult to postpone the awful truth. A poor design is inevitably more difficult to build, test and deploy. Of course, a poor development team will try to merely paper over the cracks, but the wise will stand back, scratch their heads and ask such questions as ‘how can we avoid this?’, ‘why are we getting those build errors?’,  ‘Was that ORM really such a good idea’ , ‘perhaps we need a proper interface’, ‘do we need to plan our downstream BI requirements?’,  ‘was ad-hoc SQL from the application really a good idea?’ or ‘LINQ is really cool but how do we track what objects are being referenced?’