>With software, it is especially hard. Especially as you go deeper and deeper into the components. At the UI level, it might seem easy to say what is the amount

>With software, it is especially hard. Especially as you go deeper and deeper into the components. At the UI level, it might seem easy to say what is the amount of flexibility you need. When designing a common utility or infrastructure piece to be used by everyone in a large company, it is much less obvious. There's a relatively straightforward approach to this that works well - simply don't build in flexibility until it's explicitly required or it's very, very obvious it will be required. When you're engineering mid-tier and back end the requirements can be most easily ascertained by doing the upper levels that depend on them first and working your way down. I'd estimate that 9 out of 10 times when an engineer tries to predict and pre-empt future requirements they fail and that failure is often expensive not only in wasted time but in useless extra code to confuse maintainers (and new space for bugs to grow in).