I’m unable to continue the classic mistakes series again today due to a problem one of my private clients is having with a software deployment. To help them hit their delivery date I’m rolling my sleeves up and attacking the problem, as Marku Alen, one of my rallying heroes from the 1980s’ would say “Maximum attack ! 110 percent!”
Typically some, if not all, of the problems could have been avoided.
- A merge from 2 code streams into another code stream had taken place just prior to the building of the software. There was no time for testing, not even the stored procedures have been compiled. The script to compile stored procedures into the database is failing in numerous places
- The deployment is split into two tasks, handled by two different departments. The department that handles the creation of the install kit using Installshield has one person that knows how to do this, and he’s on holiday
- The comprehensive operations manual hasn’t been updated for over 12 months, despite changes to the file server locations and an upgrade to Installshield 12
- An error produced in Installshield allows the MSI to be produced, but locks the files Installshield produces preventing another MSI to be generated in that directory. So every time the MSI is produced another directory has to be created and the necessary files copied over. This may have been overcome, but hasn’t been documented by the chap that normally handles it
How this could be avoided:
- Merging is a horrid task, very boring and easy to get wrong. In this case what should have happened is a merge from one code stream into another, fully test, or at least a smoke test, merge in the second code stream and fully retest. In adds 2 to 3 days to the merge, but it provides confidence in the application that currently isn’t there. Bearing in mind that this is almost a release candidate, releasing unstable code at this stage is foolhardy
- As a general rule never check code into shared source control system when that code doesn’t compile. There are downsides to this approach, for example amended code only existing on the developer’s computer for a period of time, but this risk can be minimised with a comprehensive backup plan. When you have more than one developer working on a code stream, I believe checking in only code that will compile is vital to prevent developers wasting their time getting someone else’s code to compile. The same applies to stored procedures
- Keep operations manuals up to date. The idea is that just about anyone in the development team could pick up the manual and produce, in this case, application binaries and the setup kit. Additional information, such as problems with Installshield can also be added to a departmental or company wiki
The Code Whisperer RSS Feed