The process of creating a great [novel, product, presentation] is iterative. You create a first version. It sucks, you find obvious flaws, and you make a few pa

The process of creating a great [novel, product, presentation] is iterative. You create a first version. It sucks, you find obvious flaws, and you make a few passes through editing it. Then you show it to other people and get more feedback. Repeat. The advantage of high-level, low-detail [outlines, prototypes, sketches] is that you can find a lot of flaws without doing all the work, and iterate faster. It sucks when you have to scrap 3 weeks of code because there's a fundamental flaw in your architecture. It sucks even more when you have to scrap 5 years of work because you built something nobody wanted. Novelist Rachel Aaron started writing 5 times faster and with higher quality (at least according to Amazon) through extensive use of outlines[0]. Now, the high-level outline will never be 100% accurate. As you dive into details, you'll realize that there are flaws and you need to change your design. That's okay. The point is to go with the approach that helps you improve faster than anything else. If you're writing a new feature for your app findthenearesthotdog.com, the right iteration loop might be idea -> 15 minutes on a whiteboard -> code. If you're creating software that has interface with 17 different legacy systems from hospitals with administrators who think web apps are made by spiders, you might want to go idea -> talk to customers -> talk to lawyers -> draw up diagrams, get approval -> write up 500 page spec, get approval -> code With the product you're building, figure out which source of feedback (yourself, customers, friends) and which level of detail (code, specs, whiteboards) will help you improve fastest, and start there. [0]: http://thisblogisaploy.blogspot.com/2011/06/how-i-went-from-writing-2000-words-day.html http://thisblogisaploy.blogspot.com/2011/06/how-i-went-from-...