The 'Child First Name 1' problem: skipping data modeling for UI wins

The CRM standard of coupling data model to user interface has sparked more emotional debates in my career than I would have expected. On one side you have people who understand the benefits of structured data. On the other, end users who just want a not-crappy UI without needing a developer or paid tool.

My first Salesforce clients were nonprofits, so I’ve had the “Child First Name 1, Child Last Name 1…” conversation more than once. Someone is sitting in front of you, you want to tab through fields and focus on them, I get it. Pre-Visualforce days I even wrote S-Controls to help square that circle. More recently, I've had to argue against merging Account Types and Ownership Types into one jarbled picklist which logic then has to be hard-code pick apart for all of the places where those distinctions matter... like populating legally binding contracts.

I understand the user experience angle, and always offer alternative solutions. But many stakeholders write me off as overcomplicating things. They don’t see how those choices affect data analysis, history tracking, logical consistency, regulatory reporting, or basic record hygiene. Or they say that they do, but would rather kick the can down the road to deal with it later.

Jump to later. Now the org has worked with both parents of many families, so data entry was duplicated (inconsistently) for the same children. Parents divorce, families merge, and kids have this funny habit of growing up, so a single child's data can be scattered across many records. So the day you realize that geeky developer was right and you do need to structure that data better, reconciling all of that is has become a Project.

I use that example because it’s easy to conceptualize, but I run into this pattern constantly. I’ve inherited plenty of well-intended shortcuts where someone avoided a proper data model for a quick UI win. The consequences hit eventually ("What do you mean we can't get a report showing how many people have children under 10, didn't you collect all of that?") and cleaning up after that decision is almost always more painful and time-consuming than just doing it correctly from the start.

Yet another entry in the tome of “slap it together as fast as you can” decisions that lead to excruciating cleanup best case, and worst case... rebuilding from scratch because the tangle of missteps is too costly to unwind. Sound architecture is worth the time, especially when you're laying the foundation of your tech.

Tangentially, for AI-assisted development, sound architecture in your codebase determines whether the LLM has a structured, predictable landscape to work from, or whether it will wander like a confused child savant, guessing at patterns that never existed. Which I suspect is one reason teams see such wildly different outcomes from AI assistance. More thoughts on that to come.

#CRMDesign #SalesforceArchitecture #DataModeling #EnterpriseSystems #AIAssistedDevelopment