Re:Programming Is Mostly Thinking
by mannykannot on Sunday April 21, 2024 @11:13AM
(#40106362)
This is the only practical way (IMHO) to do a good job, but there can be an irreducibly complex kernel to a problem which manifests itself in the interactions between components even when each atomic component is simple.
[ Parent
| on HN ]
Then the component APIs need improvement.
At the microlevel (where we pass actual data objects between functions), the difference in the amount of work required between designing data layout "on paper" and "in code" is often negligible and not in favor of "paper", because some important interactions can sneak out of sight.
I do data flow diagrams a lot (to understand the domain, figure out dependencies, and draw rough component and procedure boundaries) but leave the details of data formats and APIs to exploratory coding. It still makes me change the diagrams, because I've missed something.
Re:Programming Is Mostly Thinking
by mannykannot on Monday April 22, 2024 @09:31AM
(#40114184)
Without an argument for this always being possible, this just looks like unjustified dogma from the Clean Code era.