2 ms·

I agree, to a point. Successful design docs require MORE work (or far more meeting time, at least) than rapid prototyping. Because they need to mentally step th

I agree, to a point. Successful design docs require MORE work (or far more meeting time, at least) than rapid prototyping. Because they need to mentally step through all the logic, gotchas and integration issues without writing a line of code. For a math metaphor, it's like doing a complex problem in your head then making a document stating which mathematical tools you will use, THEN writing down the actual formula. Versus the "show your work" approach of trying a few things, recalibrating or re-routing, then settling on the final approach. So the design doc approach is truly terrible and inefficient. Except... If a Very Smart Person is making the design doc and can pump out a perfect plan quickly... And/or if the engineers implementing the solution are too junior to understand the build/rebuild approach... Or if they are likely to miss various integration footguns... Or if they are likely to go far down the wrong path completely... Or if the organization is of such size that no one has understanding of all the parts and integration parts so you need to set hard I/O requirements for clean handoffs. There may be more reasons for design docs, but I strongly agree they should only be used when necessary and certainly not required so that management gets to feel useful. They add a hefty tax to development speed and it's management's job to understand that cost/benefit ratio.

fwip 2y ago
It think it mainly depends on the difficulty of the problem. If you're working on a very difficult math problem - say, a novel proof - you're definitely going to lay out the tools and techniques, the various steps of the proof, before you sit down and start writing it out. But for homework problem #7 of 14, just start doing it - you'll figure it out. Similarly, if you're writing a CRUD app in a stack you've used before, you can probably just start. But if you're writing something complicated that you haven't done before, you should probably visit the whiteboard before the IDE.

fwip 2y ago

It think it mainly depends on the difficulty of the problem. If you're working on a very difficult math problem - say, a novel proof - you're definitely going to lay out the tools and techniques, the various steps of the proof, before you sit down and start writing it out. But for homework problem #7 of 14, just start doing it - you'll figure it out. Similarly, if you're writing a CRUD app in a stack you've used before, you can probably just start. But if you're writing something complicated that you haven't done before, you should probably visit the whiteboard before the IDE.