The people who taught you to architect programs before coding were also aware of this trade-off.
It’s a lot easier to write the small programs assigned in college that way, than the large programs you will write in the real world.
This is not the top-down vs. bottom-up debate; both top-down and bottom-up design architect first.
It is related to the concept of waterfall/iterative/incremental design; incremental designers can paint themselves into a corner.
I’ve written a lot of big programs, and I’ve never regretted the time spent architecting them. I have sometimes wished I had spent more time designing them before starting.
Fatal design errors that crop up down the road are more likely to be language-related: Your program gets so complicated that you have to rewrite it in a compiled language to run it in real-time or to avoid running out of RAM; or you discover that C++ templates don’t work as advertised, or that Java can’t allocate 2G of RAM, after you’ve already writtten 3000 lines.
The people who taught you to architect programs before coding were also aware of this trade-off.
It’s a lot easier to write the small programs assigned in college that way, than the large programs you will write in the real world.
This is not the top-down vs. bottom-up debate; both top-down and bottom-up design architect first.
It is related to the concept of waterfall/iterative/incremental design; incremental designers can paint themselves into a corner.
I’ve written a lot of big programs, and I’ve never regretted the time spent architecting them. I have sometimes wished I had spent more time designing them before starting.
Fatal design errors that crop up down the road are more likely to be language-related: Your program gets so complicated that you have to rewrite it in a compiled language to run it in real-time or to avoid running out of RAM; or you discover that C++ templates don’t work as advertised, or that Java can’t allocate 2G of RAM, after you’ve already writtten 3000 lines.