I find this approach has a number of advantages: - it forces you to flesh out your conceptual/paper design in a deliverables-oriented way and makes it obvious

I find this approach has a number of advantages: - it forces you to flesh out your conceptual/paper design in a deliverables-oriented way and makes it obvious where the gaps are, which gives you a good idea of how ready you are to wrap up design and start development, and in turn can be used to create your work breakdown structure and task prioritisation; sometimes it can result in identifying simplifications upfront (saving you time down the line) - when you have a good idea of the scope and complexity of a solution like this, you're less likely to waste time on the less important stuff - if you're the tech lead on a team, giving your developers the high-level components and tests means they're more likely to get things right (or at least limit the damage they do when they get things wrong) Without component-level unit tests or design, you can easily dive into a solution without thinking it through and really regret it.