So I’m moving on… after more than two and a half years at my current place of employment I’ve decided to kick the bucket and leave a winning team to join another, hopefully just as winning team with a bigger horizon.
But yes, I am bailing… and the extent of my bail is becoming more and more obvious with every day. Today I struggled with the spawn of satan that is one of our legacy content management tools. Like peeing into the wind, anything written in Microsoft Access is a bad idea… Let me make myself clear: Anything written in Microsoft Access is a bad idea… ever.
Even worse than that is software written by the receptionist, which this was… and the architecture proves it.
I could go on and on about why the system is bad, but I can sum it all up in 3 points:
The 3 Rules of System Development with Microsoft Access
- Do not develop systems using MS Access.
- If you do develop systems in MS Access, make sure that the architecture and development is done by qualified developers.
- If you chose to ignore rules 1 and 2, make sure that you have a roadmap for replacing your creaking MS Access system before you realise it is creaking. See Addendum 1.
Addendum 1.
The life expectancy of a system written in MS Access can be calculated using the following equation:
[days before catastrophic system failure] = 365/[days to develop]
Simply put, this means: (For the mathematically challenged)
- An MS Access application that was developed in one day will last 1 year.
- An MS Access application that was developed in 1 year will be broken by the time it is finished.
- An MS Access application that was developed over 5 years was already critically broken 4 years ago.
- The more you work on an MS Access application, the more you break it.
Hence forth shall this be known as Endersby’s Rule Number 493
HTH.
j.
