Programmer’s Backdoor Trap
Later, he was informed that DWH personnel made his life easy: They’ve decided to write the data into his own database so he wouldn’t have to work so hard.
Unfortunately this news made him happy, and therefore he went on with it, which made me even sadder.
What’s wrong with it?
1. It opens a backdoor to the system because you have to give permission to another to your
2. It’s hard to maintain. What happens when you deploy\move your database to another
server? Starts making calls to the other system’s owner so he will update his own?
3. Let’s assume you gave the permissions so the other system’s will update your database,
What happens when it fails to do so? Who will know? (a hint, not you, not at first at least).
4. What happens when you need to change your DB schema? How many system owners
will you need to inform? do you wish to keep track? (you probably won’t).
There are more reasons but I think I can leave you with the one’s written above, feel free to come up with some more on your comments.
That’s was a classic programmer’s trap
It is very tempting to have your job easier at the beginning but the price is opening a backdoor to your system, which is too high.
Fortunately it took only a while to persuade everyone that it is not the way to do things. Now, exchanging data between the databases was replaced by reading the data through a web service.
That's was one system I’ve caught at development stage. This also exists on many production systems at the customer I work for. They mainly let the integration system to write on various system’s databases which I struggle hard to prevent.
If you, as a developer, a team leader or an architect see this trap, please identify it, don’t fall and don’t let others fall into it.