Tuesday, September 21, 2004
Writing Solid Corruption-Free Code
I recently heard of some programmers struggling with mysterious data corruption issues with their application. I was struck by their similarity to something I'd seen almost a decade ago. Back then, I was building database-backed CRM applications.
Plan "A" for such applications is simple: always write good data. Plan "A" lasts about a month into any project. Once change requests a/k/a maintenance and upgrades appear, it's easy to introduce new code that writes something the old code doesn't expect, and you have corruption.
Plan "B" usually kicks in at that point. You introduce constraints at the row level, using as many tricks as your database vendor provides (triggers, &tc.) to validate data before it's written. Plan "B" lasts for two more months before the sheer complexity of your object relations weighs in. Then you find out that saving records now takes forever, and it's hard to maintain your application when a lot of the validity logic is hiding in your database.
Plan "C" now takes over. You remove most of the slowest and most complex validity checks and move them into a batch process. You add some support for rollbacks, such as a "valid" flag. You run the validity checking on a nightly basis and as part of major data imports and updates. The validity checking is now all in once place, so it serves as documentation.
A funny thing now happens. As you develop new code, you find that you can consult the validity routines to understand what consitutes a valid state for the database. If you need to add new modalities, you can add new validity routines. It's better than a UML diagram because it's executable code.
Debugging is now a cinch. Validate the database. Run some tests. Validate again. If the second validation fails, you have bugs in your code.
Two years ago I introduced this idea to a project. I asked the project's database analyst to write a validation routine for a complex application. He replied that he couldn't, the application was too complex for that. His idea was that we'd follow his meticulous plan and everything would just happen to work.
Red flag! If the DBA can't write the routine, then there's zero chance the final application will work. As it happened, it was impossible to write new code for that application. There was a complex, table-driven workflow infrastructure and nobody could ever construct a baseline set of rules and states to use for testing code. I heard that they eventually junked it in favour of an off-the-shelf solution.
So now I'm going back to the well when advising my friends.
Their application serializes a dense object graph out into binary files. From time to time it seems to do unexpected and unwanted things. Debugging seems to be 50% Voodoo and 50% thought experiments.
I'm urging them to stop thrashing and start writing some external validation routines. It hurts to do that, but I'm certain that they'll reap serious dividend both in solving their current issues and when writing new code in the future. If they have a validation routine, one of the great things they can do is set upa debug mode that validates every single write.
If nothing else, I'll wager anyone dinner for two with a bottle of wine (I'm serious about this) that the very act of wading through their data format and deciding how to write a utility that can validate their data will cause them to kick themselves at least once and say "Aha! I see a problem!"
Plan "A" for such applications is simple: always write good data. Plan "A" lasts about a month into any project. Once change requests a/k/a maintenance and upgrades appear, it's easy to introduce new code that writes something the old code doesn't expect, and you have corruption.
Plan "B" usually kicks in at that point. You introduce constraints at the row level, using as many tricks as your database vendor provides (triggers, &tc.) to validate data before it's written. Plan "B" lasts for two more months before the sheer complexity of your object relations weighs in. Then you find out that saving records now takes forever, and it's hard to maintain your application when a lot of the validity logic is hiding in your database.
Plan "C" now takes over. You remove most of the slowest and most complex validity checks and move them into a batch process. You add some support for rollbacks, such as a "valid" flag. You run the validity checking on a nightly basis and as part of major data imports and updates. The validity checking is now all in once place, so it serves as documentation.
A funny thing now happens. As you develop new code, you find that you can consult the validity routines to understand what consitutes a valid state for the database. If you need to add new modalities, you can add new validity routines. It's better than a UML diagram because it's executable code.
Debugging is now a cinch. Validate the database. Run some tests. Validate again. If the second validation fails, you have bugs in your code.
Two years ago I introduced this idea to a project. I asked the project's database analyst to write a validation routine for a complex application. He replied that he couldn't, the application was too complex for that. His idea was that we'd follow his meticulous plan and everything would just happen to work.
Red flag! If the DBA can't write the routine, then there's zero chance the final application will work. As it happened, it was impossible to write new code for that application. There was a complex, table-driven workflow infrastructure and nobody could ever construct a baseline set of rules and states to use for testing code. I heard that they eventually junked it in favour of an off-the-shelf solution.
So now I'm going back to the well when advising my friends.
Their application serializes a dense object graph out into binary files. From time to time it seems to do unexpected and unwanted things. Debugging seems to be 50% Voodoo and 50% thought experiments.
I'm urging them to stop thrashing and start writing some external validation routines. It hurts to do that, but I'm certain that they'll reap serious dividend both in solving their current issues and when writing new code in the future. If they have a validation routine, one of the great things they can do is set upa debug mode that validates every single write.
If nothing else, I'll wager anyone dinner for two with a bottle of wine (I'm serious about this) that the very act of wading through their data format and deciding how to write a utility that can validate their data will cause them to kick themselves at least once and say "Aha! I see a problem!"
Comments on “Writing Solid Corruption-Free Code”:
<< Home
Good idea. In a similar vein, I've been toying with creating some validation routines to ensure that our users create data correctly. We're customizing a (big) proprietary program and we've toyed with the idea of restricting users' input to valid values, but we're afraid of over-constraining, and it would be a lot of work (given the software's architecture). Instead, I've proposed that we have a daily script that searches through the database for errors we've seen in the past and emails us (and perhaps them) with any problems. We can add search criteria as we run into new user blunders. It will also allow us to give quick feedback when they do something wrong, which will help to break some of their bad habits.
<< Home
