Much of database development work involves controlling data, access to data, defining what data is allowed into the system, and what rules govern the interaction of data manipulation and data definition. Well designed database systems are frequently secured, controlled, defined, constricted so that only specific data, in only the exact type and only in certain sizes, are to be allowed. All this is carefully crafted by the database architect.

And yet for all the careful design there is no absolute certainty that the database will be used as intended or imagined by the creator. There is no absolute certainty that the database design will not change, drift or shift in small or large ways.

This principle of uncertainty in the design of database systems means that the developer of the database should come to terms with the evolutionary tendency of information systems whether or not the original developer participating in the evolution of the database design.

So the uncertainty principle of database designer work has further implications as we ‘let go’ of control of our database systems. I’m speaking of when you shift jobs or pass on development work to another developer while you take up another project.

If you are mindful developer, keeping design documentation to pass onto new caretakers as well as answering phone calls will be important. The other thing is that there is a continuous sense of joy when a database system you have helped to create is passed on and ‘standing on its own’ and growing.