Tales from the messagebox: Not just the happy path!

When you’re designing and implementing a solution don’t forget there’s more to it than the “happy path.”

It’s going to break.

It’s a certainty that at some point something will break. You’ll get a call from users asking why they’re not getting output, or not getting the output they expect. How will you resolve this?

Leave yourself a trail of breadcrumbs.

Have you saved logs and archives of inputs and outputs? These can be invaluable in investigation and recovery, but don’t forget to secure any sensitive data! Ideally they should be on a separate write only system. Should the main system be compromised you can trust the logs to help determine the impact.

Since BizTalk uses XML and not JSON don’t forget you can embed comments in your messages. Comments are ignored by automated processes, but a comment in an archived output explaining the choices it made can be a life saver. Don’t forget to include the inputs. If data is changed after a process runs it may be nearly impossible to understand what happened after the fact.

What you didn’t check can kill you

At one employer a dev lead I worked for never considered this. He was updating a query that added a year to a customer’s subscription ending date if they met the right qualifications during the month end processing.

He commented out the SQL WHERE clause during his testing and forgot to restore it when producing the production version. Net result was tens of thousands of subscribers received an additional year of service they weren’t qualified for.

He caught it immediately when the monthly process ran and tried to restore to the latest backup. He found out there were no backups. The database team that handled backups informed us we had the level of service that included backups, but we did NOT have the level of service that ensure the backups actually succeeded. The SQL server agent running the backup code wasn’t running for weeks so the backups we did have were significantly out of date.

How did this happen? We had processes in place.

He tested his code to ensure those who deserved another year got another year. He did NOT test the inverse. That those who did NOT deserve another year did NOT get it. He could have saved his career with that one test.

The QA department checking his work failed in the same way. They created a database of deserving clients and all of them got their addition year of service. There were no records for clients that didn’t meet the criteria. QA PASS.

Test for failures too!

Create tests for more code paths. Ideally keep these tests so other developers can run them and have better assurance they didn’t accidentally break code they didn’t change.

Hopefully now you’re forewarned you’ll not fall prey to this kind of mistake.

Happy coding!

Jay

Tales from the messagebox: Database horror tales

In one sense it’s not the worst code I’ve ever seen. In another, it is.

The worst I recall was when a Visual Basic (6) coder created an application that implemented the real estate licensing test. After completing the test for one state they were asked to implement a second. So they opened the visual layout editor and proceeded to draw the second quiz form on top of the first one.

Imagine trying to maintain two forms jumbled on top of one another. In the form open event he made all the controls for the selected state visible, and all the others invisible. It was awful, but understandable. If you weren’t aware you could have two forms and just load the one you needed…

I think I want to give the title of worst to the guy (or girl) who created a database with primary keys that are the datetime type. It worked when it was tested with an empty database. Now I’ve got to support the thing with millions of rows and I’m not allowed to fix it. “It will cost too much.” It’s okay to let it randomly fail when you get collisions, perform badly, and pay for tech support to handle tickets though.

Small things do matter, and bad choices do come back to haunt you.