Read a great little post from a dev reflecting on what they have learned over the last 30 years building systems. They say.
Doing the screens first and persistence last is a common top-down approach and it is a very bad mistake
I respectfully disagree. But we also shouldn't just do screens first and not consider the persistence (modelling) of the data. Let's talk about the problem and a better way to build high quality software that lasts.
The big problem
Like many things in life, the sure thing is change and death. Software is no different. Projects start off at a great pace, with enthusiastic engineers and users, but over time they accrue cruft. Before you realize it, the project is a nightmare to change. Velocity crawls to a halt. People leave, new engineers take forever to learn the software. It's a 'giant ball of mud'.
Is 'screen first' or 'data model first' going to get you to your inevitable demise faster? I think this is the wrong question! Taking an absolute view is absolutely the wrong way, and will lead you to many WTFs on the project.
A 'data model first' approach wil harden and become brittle to new and unexpected ways of querying the data. It will accrue cruft related to features that are never needed. In my experience I've seen teams sink big amounts of time in to work that is never needed, which just clutters the way forward and makes the software harder to work with.
'Screens first' as a mandate is no better. Projects that do this end up in what I call 'firebase hell'. There is often no data model, confusing denormalisation. Sometimes, if you are in a special hellish place, you might end up with a nosql model when a relational model is desperately needed. This is an avoidable nightmare if you consider the data model from day one.
Why do we take these hard positions on one side or the other? Is it a skill issue? I say no, I think it's natural -- it happens, don't beat yourself up reader, we all make mistakes. How do we fix it?
The perfect team
We need the three musketeers of software development. Product, backend and design. We need to make sure the solution actually solves the problem by (product). A designer to make the screens to solve the problem, and a data modeller to give us a model that scales beyond the life of this one application. Including this diverse set of mindsets is critical. It allows a team to succeed in the short term, while laying a foundation that can be built on in to the future.
If you're working on your own, it's important to wear all the hats. Don't worry about being balanced or perfect at all of these, it's ok to be specialized in one area. Just respect that these points of view are of equal importance!
The designer is going to make screens which you can put in front of customers, validating that they solve the problem. Do not worry about making pixel perfect figma designs. My favorite prototype tool is a screenshot or simple powerpoint. Use what works best and fastest, some developers I know like to do this with plain html/css if that is there jam. There are interesting AI tools that might even work in this space such as v0.dev. The important part about this is to ask the right questions when you are talking to the customer. Ask "What is your biggest problem with the existing solution?" "Show me how you solve the problem now?". Listen very hard to their answers, build many iterations of the screens.
A good data modeller is going to be able to sit in on these interviews with customers, and their mind will spin with the ways you could persist and model this data. A graph, a document store or a relational database? The modeller will ask questions to tease out the best data model, validating or invalidating the mental model.
In an ideal world, this happy trio of people (or alternate personalities), is going to be able to quickly iterate and test ideas and models of the system. I can't stress more how important it is to have everyone along for the design journey.
Wrapping this all up
So if you've made it this far, I hope you are convinced that the absolute position of 'screens first' or 'data model first' comes from a place of pain, and will end in pain. It's a natural reaction to a bad experience. Instead, try and think about the problem you are solving, and the people you are solving it for. Try and get a good team together (or adopt multiple personalities), and iterate on the design and data model. You will be rewarded with a better product, and a better experience building the software.
Top comments (0)