Start with a Minimum Viable System (2023)

Lots of people make this mistake many times before learning this. I enjoyed this perspective.

This is covered as Tracer Bullets in the book The Pragmatic Programmer. If anyone hasn’t read that book, I strongly recommend it. Should take an afternoon or two and covers the top 100 most popular blog post concepts that make it on HN.

Agreed. Shipping earlier and often gives the project lots of traction and makes it easier to prioritize features and to correct system requirements.

When I'm asked, I often suggest taking the opposite route, though: build the UI first, then the backend to support the UI, and finally, the database schema that best models the business. In my experience, this approach makes it easier to spot edge cases while also making clear what the deeper layer should really support.

This isn't a new practice; it's a Walking Skeleton https://wiki.c2.com/?WalkingSkeleton

one technique i have used is to start with a focus on the data model, then hand-drawing a UI (on paper or a whiteboard) to validate the models and reveal any holes or opportunities to better map the data. i will draw out UI's for consecutive steps using this technique, and keep track of the how the records in the database would change, again on paper or whiteboard. from here, i'll seek to isolate the "hero path" through the use case, then consider other personas and what they may want to see.

then, you gotta get away from the work - go on a walk, or better yet spend at least 1 hour in nature. enough time to disconnect from the problem. it's so important at this phase to get away from my previous mind-space and to not listen to music, podcasts, or soak in any other ideas. i know if i spend enough time looking at leaves and moss, touching dirt, or talking to my chickens, i will truly activate my background job runner in my brain, which will crunch away at this.

return to the studio, and do this process several times. resist the urge to write code or use a computer to draw UI's or whatever. keep it in your brain, where thoughts are plastic, and utilize my hands to draw and give those intangible thoughts a physical form. i close my eyes and visualize every flow, every click, every read and write to the database.

this happens in a loop, hopefully for several iterations, across multiple days to weeks. starting, re-starting, stopping, iterating. again, stay away from a computer until the iterations start to reveal the real edges of the problem i'm working on. once it feels like i can close my eyes, see the paths, understand the data and its transitions, then (and only then) is it time to write some code.

the trick for the next part is to build out the necessary stuff to implement this rudimentary understanding, using the most minimal code possible. then, i'll make a UI as quickly as possible so my brain can start to have a foothold on the growing system and map the increase in fidelity to my mental model.

most of the systems i have built that start with high-fidelity prototyping end up with a lot of rework. whenever i skip the early phase and necessary day-dreaming, i always end up paying for it in some way. the myth of the systems developer sitting in front of a computer, silent, barely moving and somehow being magically productive on early-phase work doesn't reflect my personal experience. we are all beautiful and unique, and of course we work in different ways - but i have found that shortcuts like early-phase productivity lead to diminishing returns and an altogether less fun systems development experience.

...duh?