Scribbled notes: Blind spots as developers. Working notes. Assumptions.

Blind spots.

A not-so-recent project I worked on convinced me that well meaning assumptions can cost us frustration and time.  I was tasked with fixing a bug where duplicate records were showing up in a search tool for certain financial data.  The more I tried to understand what the code was doing (specifically a SQL join on an arcane AS400 database), the more confused I felt.

Finally, I realized that the original developer had assumed that certain columns were meant for JOIN conditions, when in fact that assumption was utterly wrong.  The data relationships were much looser than originally thought, and the data simply could not be displayed in the old way anymore.  To fix the bug, I had to redesign the report with progressive disclosure at each level.

The original developer had trusted some (wrong) intuition, and what some accountants had probably told him.  I had trusted that the original application SQL was written with a correct concept of the data model.

We all have blind spots.  I've since learned not to trust that the original design was even correct (it was good enough to get by on, but it confused and frustrated people often).

(The original query had joined on "line item numbers", but a check line item isn't the same as a document line item--they are only related by document, not line number; checks could be written for multiple documents, and documents could be handled by multiple checks)...

Anyway, just watch out for assumptions.  You have to make them and live with them, but just be aware of them and list them, before you forget you made them.  Keep working notes as you do your job.  They'll get better over time.