> I'd rather get to value now by making something that just works(and is adequately tested) than engineer something thats future proof but takes longer to get o

> I'd rather get to value now by making something that just works(and is adequately tested) than engineer something thats future proof but takes longer to get out. If you haven't read it, I highly recommend A Philosophy of Software Design by John Ousterhout. His talk is a great teaser for the book: https://www.youtube.com/watch?v=bmSAYlu0NcY https://www.youtube.com/watch?v=bmSAYlu0NcY Here's the thing: a program properly written for the future does not take longer to get out. Not much, at least. What we instinctively think of as "future proof" is generally anything but: by anticipating some particular kind of change that may happen some time in the future, but in practice almost never does, we end up with more complex programs that are harder to modify when an actual (typically unforeseen) change comes our way. The best way to future proof your program is to make it simpler, according to the requirement you are currently aware of. If you expect a particular change, sure, plan for it. But for the unexpected, just keep it simple. Because simple is easier to adapt, add to, or rewrite. That said, the simplest solution is rarely the most obvious. Making thing simple does take a bit more time than rushing through the first thing that comes to mind. But it also pays off in a matter of weeks, so it's quite worth it. And if you have a hard time assessing what "simple" means, SLoC is a surprisingly good metric (we have research that shows this). And mostly your modules should be deep: small APIs that hide significant implementations. I think of it as encapsulation on steroids.