But what are you balancing? In most cases, when you get down to it, what you’re balancing are the perceived/expected needs of the future against the needs of the moment. In conjunction with the known cost now compared to the potential cost later.
The needs of the moment are clear. Your customers are talking to you about them daily. You’re looking at metrics and error rates and other real-time feedback. You’ve committed to delivering something specific to solve a specific user problem.
Then there are future needs. Some are easier to predict/quantify than others. Someone, likely you, will need to maintain the code you write today. Usage will probably go up. Computers will get faster. Data rates will almost certainly increase. You can count on those things. You should design and code for those changes. It might cost a little more now, but it will pay off tomorrow.
Other future needs aren’t as easily knowable/quantifiable. Will you need microservices next year? Will your domains change, and if so, how? How will market changes impact business goals? What’s your vision and mission, how might they change, and what impact will that have on your plans? And if you don’t know the changes, how can you know the cost of those changes?
Which leaves you to balance the two timelines. You need to think enough about the macro/long timescale side of things to keep from painting yourself into a corner. You need to move quickly and solve today’s problems today. You can’t spend so much time thinking about the future that you don’t take care of the immediate. You can’t spend so much time working on the immediate that you never plan for the future.
You need to keep the two in balance.