I always write "front-to-back". I write the code that uses a module, abstraction, api, etc. Then I write that layer until the code works. This goes on layer to layer.
To make it not become a tour-de-force, I start with a golden path, then various aspects (validation, additional operations on data besides rendering, etc). If the data doesn't exist yet, it's mocked. Then later, it's implemented (or made 'live') according to the mocked "schema".
It's not exactly TDD (I rarely write a test except for integration tests or the occasional "let's make sure it's not off-by-one").
It's not top down either, exactly. Perhaps you could call it "needs driven development" or "user driven development". You need it from the start and you use it as soon as possible. From then on, it's just improvements.
If you work back-to-front, you won't have anything working until late in the game. You're constantly imagining all the non-consequential "what-ifs".
But in a way, front-to-back is like TDD except you're not testing via unit tests. You're testing by using. And you will be using it so much that it will be tested thoroughly. You iterate continuously while the top layer / front end keeps working.
Sure, there can be an overarching design. There can be an architecture. There should be. But after that, it's about slowly molding the system towards that design. If you have understood the design, you know when you're veering off course. For sure, it's not like building a bridge.
You can get something similar with back-to-front. You don't have to spend your time imagining.
With front-to-back, you mock out data. With back-to-front, you mock out interfaces. This is how I write Django projects. I write models, which I can start using right away. Sure it's in the REPL, tests, or admin pages. But I'm using real functionality with real data from the very beginning. Then the custom views and templates get added on top.
I love user-driven design as phrasing. Although I neglected to mention it, I quite often write basic cypress [1] tests early on to get a TDD-like experience.
> For sure, it's not like building a bridge.
It's super interesting how many processes are inherited from traditional engineering.
Hm. Maybe.
In my experience, tests is just more code, more bugs, more maintenance. If you need to write many tests, you're writing your code wrong. "Just my opinion, man" ;)
"For example, I previously tended to use a bottom-up approach to development. However, SICP showed me the benefits of what it calls "wishful thinking" with a more top-down approach."
Pretty good representation of my work flow. I generally save the details (permissions, validations, test coverage) for the end of the process, once the architecture is more solid.
Some projects I spent more thinking on, but especially where specs and design are more vague, I approach it from front to back
To make it not become a tour-de-force, I start with a golden path, then various aspects (validation, additional operations on data besides rendering, etc). If the data doesn't exist yet, it's mocked. Then later, it's implemented (or made 'live') according to the mocked "schema".
It's not exactly TDD (I rarely write a test except for integration tests or the occasional "let's make sure it's not off-by-one"). It's not top down either, exactly. Perhaps you could call it "needs driven development" or "user driven development". You need it from the start and you use it as soon as possible. From then on, it's just improvements.
If you work back-to-front, you won't have anything working until late in the game. You're constantly imagining all the non-consequential "what-ifs".
But in a way, front-to-back is like TDD except you're not testing via unit tests. You're testing by using. And you will be using it so much that it will be tested thoroughly. You iterate continuously while the top layer / front end keeps working.
Sure, there can be an overarching design. There can be an architecture. There should be. But after that, it's about slowly molding the system towards that design. If you have understood the design, you know when you're veering off course. For sure, it's not like building a bridge.