More lessons from the trenches, and of the worst sort. There are some mistakes that seem to get made over and over again. You stub your metaphorical toe, recognize the rock, swear you’ll take care of it, and then wham! There’s that stupid rock again.
Define your terms. Explicitly. In writing.
In this case we had data being passed through three layers of services with three different companies after importing data from yet another service at yet another company. Everyone involved uses a different subset of the data and has their own data models. And their own field names. What we failed to do was document a data dictionary showing how those fields mapped between models. Normally this sort of problem would have surfaced early in testing, but there was other factors that hid the damnable rock and we’re lucky we didn’t break a toe this time.
Document your terms. Document your assumptions. Find a way to get everyone to actually read the documentation and update it when things change. And make sure you are testing those definitions and assumptions, somehow. And the more parties you have involved in a project, the more critical this becomes.
Now, how the heck do I avoid being involved in this sort of toe-stubbing exercise again? I don’t have the answer to that one.