I never used punch cards, but I did use floppy disks. Big ones, small ones, the kind that clicked when you slid them into the drive. No matter how small the storage was back then, the basic operations were the same: create, retrieve, update, delete. We have been doing those four things for decades, and by now we know how to do them.
Writing to a local disk, a removable disk, or some cloud store up above: the mechanics change, but the pattern does not. CRUD is like accelerating, braking, and turning the wheel. We got that part down. The harder question is always where we are going, why we are going there, and the best route to take.
The System Is Bigger Than the Screen
When I build software for a business, the automated system is rarely the whole system. It is one piece of a larger process that includes people, paper, phone calls, spreadsheets, habits, and exceptions nobody documented. The most valuable work is understanding that bigger system and figuring out where the automated piece fits.
I have watched teams spend weeks designing screens for maintaining lookup tables. They polish validation rules, build bulk imports, and debate field lengths. Then they run out of time to think through the actual workflow those lookups support. The workflow gets bolted onto an incomplete process, and nobody is happy with the result.
The data matters, but the data is not the point. The point is what people do with it.
Workflows Vary More Than CRUD
Two companies in the same industry can use the same nouns and still operate differently. They both have customers, orders, and invoices, but the sequence of decisions, the handoffs, the approvals, and the exceptions are theirs. That is where the real difference lives. That is also where the real risk lives if we guess wrong.
This is why I want the workflow in front of people as fast as possible. Not a perfectly configurable one. Not one with an admin portal for every reference table. Just the core flow, with enough hard-coded or seeded data to feel real. Once people click through it, the conversation changes. They stop talking about hypothetical screens and start pointing at the actual work.
Seed the Data, Learn the Flow
If a workflow needs reference data, I assume the data will be there. I hard-code a starting set, run a seed script, or paste in whatever gets the feature moving. The important thing is to validate the workflow with the people who will use it. Once that is working, then we can plan how the data gets created and maintained.
There are many ways to populate data, and we have already explored most of them. The harder problem is getting the workflow right. So I start there.
- Abstract CRUD or defer it.
- Hard-code or seed reference data to move fast.
- Validate the workflow with real users.
- Come back to data maintenance once the flow is solid.
CRUD is solved. The workflow is not. That is where I want to spend my attention.
Leave a Reply