alt Hacker NewsIt’s not about the specific timeframe. It’s about something that has no value for today’s context superseding something that do. It’s ok to anticipate changes, it’s not ok to act as if they’re already here when it’s clear that they’re not.
And the other axis is the lean towards complexity.
Let’s say you need to add logging for a web app to be able to quickly troubleshoot it. The design was to create a simple module that printf to stderr. But then the dev comes to you with a new complicated design involving elastic search and what not, saying that we will need it in 3 weeks to dissect the logs, etc. It may have been a good idea, but it’s not valuable. The correct idea is to put that on the backlog, not to start writing code for it.
Implementing complicated idea takes more time than implementing simple idea, while the value is the same.
When there’s a need for having something elastic search for the logs, it will be easy to refactor the simple code that we have than fixing the possibly flawed implementation that would have resulted if we went with the complex design.
> It’s about something that has no value for today’s context superseding something that do.
But this is incorrect. Chet is saying "if we interpret today's requirement this way, what we do today has no value, if we interpret today's requirement this other way, what we do today has value". (and if he is in fact not saying that, the problem is that you and the author have no idea if he was saying that or not, you just saw "3 weeks" and concluded, incorrectly, that it is not about today's requirement)
Please check my other comment for an illustrative example.
> Implementing complicated idea takes more time than implementing simple idea, while the value is the same.
That is factually not true. Take my illustrative example of my other comment: Day 1 requirement has ABSOLUTELY NOT VALUE if the devs that implement it don't listen to someone who said "in Day 5, we will be in this situation, so Day 1 requirement has only values if done this way and not that way".
> Let’s say you need to add logging for a web app to be able to quickly troubleshoot it. ...
Your example does not prove anything. We here all agree that over-engineering is a bad idea, and we can all come up with example where it is done.
What you need to do, is to demonstrate that ignoring what we already know for sure will happen in 3 weeks will never be less efficient than taking 5 minutes to pick the correct solution between two simple solutions, one compatible with in 3 weeks and one not.
This is how you demonstrate. If you say "f(x) is always positive", the demonstration is not to present some x values that are positive, the demonstration is to find a way to show that there is no x values for which f(x) is negative. If you restrict yourself to "let's assume that Chet solution to be compatible with the situation in 3 weeks is complex and will not be needed", of course you will conclude what you conclude. What you need to do is to convince us that it is impossible to have a situation where the information of what will be in 3 weeks will never be useful.
Because this is the point: in the situation in the article, the author has not enough information to know if Chet solution is complicated or not something needed. In fact, according to Chet, it is something needed, and the simple solution has therefore __zero value__.