I generally do "outside-in" development, but only after I understand what I want the software to do as visible (observable) by a user (or other system). I'll sk

I generally do "outside-in" development, but only after I understand what I want the software to do as visible (observable) by a user (or other system). I'll sketch the UI, find the UX flow for the "things to be done", etc. This defines the "outside". Once I have that, I get detailed enough on the UI, either by writing some code, or understanding what information it needs to get from and send to the underlying parts. As soon as possible, I write an automated test that defines the behavior I want (which fails), then "move inward" to the next boundary, such as the Use Case/Service layer (I use Hexagonal Architecture), write a (failing) test at that layer, and then start implementing some behavior. I'll refactor, which often leads to the creation of a new class with a bit of behavior (this is the "inside"). I'll TDD that new behavior until it's all Green. Then I'll go back out to the Use Case boundary and write more tests/code, TDDing at that level, with continuous refactoring to extract new classes. Once I'm done at that boundary, I'll return to the Outside/UI test and if it passes, I'm done (and maybe I have some UI cleanup to do). If it fails, that tells me I need another spiral down the boundaries (toward the inside) and then back out. At each boundary, I may pause and do some CRC Card (class-responsibility-collaborator) design work, if I feel I don't have a good sense of what I'll need ("do I need a Group class here, or will the existing Roles for a User be enough?").