2 ms·
I'm certainly a "simplest thing that could possibly work" type of guy as described in David's post. A somewhat unspoken but generally understood part of this p
by georgemcbay 14y ago
I'm certainly a "simplest thing that could possibly work" type of guy as described in David's post.
A somewhat unspoken but generally understood part of this philosophy is that while you don't go out of your way to make things super flexible, you also make sure you don't code yourself into a corner that will be hard to get out of should the requirements change.
Knowing how to balance this sort of thing well takes years and years of experience (IME) but it certainly isn't impossible.
As a side note, something taking "days to fix" is no big deal considering a big part of the desire to not over-architect is to avoid situations where a fundamental and ultimately bad assumption results in a situation that is going to take months to fix with the result being a mostly new and untested code base and all the pain that comes with that.
- dasil003 14y agoHalf of this is understanding the probabilities of certain things happening. This involves estimation of both known and unknown unknowns. The other half is knowing how to keep things flexible without having to write a lot of extra codes. Where are the architectural choke points to apply the tourniquet to allow for later expansion? Aside from being an expert in abstraction, domain knowledge is also a key component to make these decisions. You're right that it takes years to become competent at it, and even then there's a good amount of luck involved.