Here are my recommended truisms for IT development tasks, particularly in the context of Content Migration.
- Document new design assumptions.
- Question stupid approaches.
- Validate deployment approach with timing numbers.
- Use challenging artificial unit test scenarios.
Document new design assumptions
It’s orders of magnitude more effective to verify the correctness of minor assumptions during development, than to find them as bugs during release or even worse after go-live. E.g. no folder or file name will be longer than 50 characters, the network path for the production import will be the same as in the test environment, the script will parse for 4-character and 3-character extensions but not character extensions, or the import needn’t create a folder if all its contents are excluded types.
Question stupid approaches
If any requirement is too time-consuming to fulfill as originally planned during solution design, escalate the issue. Perhaps it is a better project decision to modify the network data (renaming files or assigning owners) than it is to implement a very complex import process that handles it manually. Or, perhaps it’s unworkable to modify 6,000 file names and it is better that a script handle the scenario.
Validate deployment approach with timing numbers
Capture some timing information to confirm assumptions made about how long the production import will take. If it’s far slower (or far faster) revisit the deployment approach to make sure it’s still appropriate.
The unit test really should use some dummy data to ensure that things work properly – i.e. the unit test tests out the really challenging data boundary conditions without needing a bulky real customer data example. Create a sample folder structure, with sample files, with particular names and structures.
This article is part of a series discussing many aspects of content migration from an unstructured storage system to a document management system. The overview page is here: Content Migration to a DMS – Articles.