Comment by pydry
14 hours ago
The number 1 issue Ive experienced with poor programmers is a belief that theyre special snowflakes who can anticipate the future.
It's the same thing with programmers who believe in BDUF or disbelieve YAGNI - they design architectures for anticipated futures which do not materialize instead of evolving the architecture retrospectively in line with the future which did materialize.
I think it's a natural human foible. Gambling, for instance, probably wouldnt exist if humans' gut instincts about their ability to predict future defaulted to realistic.
This is why no matter how many brilliant programmers scream YAGNI, dont do BDUF and dont prematurely optimize there will always be some comment saying the equivalent of "akshually sometimes you should...", remembering that one time when they metaphorically rolled a double six and anticipated the necessary architecture correctly when it wasnt even necessary to do so.
These programmers are all hopped up on a different kind of roulette these days...
Sure, don't build your system to keep audit trails until after you have questions to answer so that you know what needs to go in those audit trails.
Don't insist on file-based data ingestion being a wrapper around a json-rpc api just because most similar things are moving that direction; what matters is whether someone has specifically asked for that for this particular system yet.
.
Not all decisions can be usefully revisited later. Sometimes you really do need to go "what if..." and make sure none of the possibilities will bite too hard. Leaving the pizza cave occasionally and making sure you (have contacts who) have some idea about the direction of the industry you're writing stuff for can help.
I spent ~15 years in life sciences.
You're going to build an audit trail, no matter what. There's no validated system in LS that does not have an audit trail.
It's just like e-commerce; you're going to have a cart and a checkout page. There's no point in calling that a premature optimization. Every e-commerce website has more or less the same set of flows with simply different configuration/parameters/providers.
Going "what if?" and then validating a customer requirement that exists NOW is NOT the same thing as trying to pre-empt a customer's requirement which might exist in the future.
Audit trails are commonly neglected coz somebody didnt ask the right questions, not coz somebody didnt try to anticipate the future.
> Audit trails are commonly neglected coz somebody didnt ask the right questions, not coz somebody didnt try to anticipate the future.
But how do you ask "the right questions" without imagining many future possibilities and then trying to discern which ones are important?
It seems like a distinction without a difference to me.
> poor programmers is a belief that theyre special snowflakes who can anticipate the future.
Some of us are actually reasonably good at anticipating the future, and don't mesh well in environments where people claim to care about quality but are always deferring stuff for the next release.
> This is why no matter how many brilliant programmers scream YAGNI, dont do BDUF and dont prematurely optimize there will always be some comment saying the equivalent of "akshually sometimes you should...",
You write as if there are no brilliant people doing BDUF. This is unequivocally false.
> remembering that one time when they metaphorically rolled a double six and anticipated the necessary architecture correctly when it wasnt even necessary to do so.
You've doubled down on the gambling trope. Any development is gambling. Thinking otherwise is foolish.
Sure, people who live and breathe YAGNI gamble in different ways, but they still gamble. I can't count the number of times I've made the statement "but if this happens and then that happens, it will be bad" which was countered with "but what are the chances of that?"
Look, if you have to ask, the probability of it being a problem at the customer approaches one.
My personal solution?
I went to work for chip companies. Chip companies have to put a stake in the ground and work to build something that they will be able to sell as designed and implemented.
This doesn't mean that there isn't a triage for features, or the potential for feature creep, or that there isn't a triage for the most important bugs right before tapeout, but the process that works and gets you a chip that customers will use is much closer to what people call BDUF than it is YAGNI.
Aye. The number one way to make software amenable to future requirements is to keep it simple so that it's easy to change in future. Adding complexity for anticipated changes works against being able to support the unanticipated ones.