[inerte]

I have an engineer on my team that's always asking "what if this or that happens in the future?" to which I've started to reply "what if it does NOT?"

I know, I know... wow. Not much insightful. But for some reason with this particular engineer this is the starting point to talk about actual requirements. This question in particular triggers the conversation of going back to product to figure out what they truly know they want right now, not in a maybe future. What are the actual hard, known requirements, instead of wishful thinking and "if everything goes well we will need this" type of mentality of ~hopeful~ optimistic PMs.

[palata]

I find that these discussions happen in teams that lack experience.

It's common for junior engineers to want to over-engineer stuff: they want to pull this cool library, they want to try this nice pattern, and over all they want to make a good job and a complex architecture sounds like they put more effort into it than a two-liners. That's why junior engineers are not the team lead.

As the lead, many times it's difficult to prove why it's over-engineering. You can often only say "hmm what you suggest is pretty complicated, requires a lot of effort, and in this case I don't think it's worth it".

What makes your take more valuable than the junior engineer's take? Experience.

Now don't get me wrong: it does not mean AT ALL that juniors don't bring anything valuable. They often bring great ideas. But their lack of experience means that sometimes it's harder for them to understand why it's "too much". The lead should listen to them, understand what they say (and by that I mean that they should prove to the junior that they understand), and then refuse the idea.

If a junior feels like the lead is incompetent (i.e. does not understand their ideas and selects inferior solutions instead), then the team is in trouble. And in a way, it is the lead's responsibility.

[Otek]

The question “what if it happens” is important but useless without “how likely is that to happen” and “if it will happen how much time we need to cover for it”

[the_af]

Agreed. This is well studied in software engineering though, I think I've read papers from the 70s/80s addressing this about risk mitigation: what is the impact of the risk if it materializes vs how likely it is to materialize?

When people argue about the rigor of software engineering (i.e. "is it really engineering?") they often forget an important part: we are doomed to repeat mistakes or reinvent the wheel because nobody ever reads the existing research, nobody learns from the past, we're always blogging about the trendy latest thing withour asking ourselves "maybe someone in the 70s already explored this and drew valuable lessons?".

[Swizec]

> we are doomed to repeat mistakes or reinvent the wheel because nobody ever reads the existing research, nobody learns from the past

We do. There’s dozens of us!

Here’s the thing though, the number of programmers in the world has been doubling every 5 years or so for the past few decades. If you have been doing this for 5 years, you have more experience than half the industry. It’s a young field and information only propagates so fast. You too have the power to help it spread.

[RHSeeger]

I tend to approach it a similar way...

- If we do it <this way>, will <this requirement> be impossible to implement (without a huge rewrite cost) later? If so then, if <this requirement> is a realistic possibility, consider <this way> is probably a poor choice

- If we do it <this way>, will <this requirement> be harder to implement, but not terribly so? If so, then weigh the cost/probability of doing it and it not being needed vs not doing it and it being needed

- If we do it <this way>, will <this requirement> not be any more cost to add then if we did it now? If so, then don't do it now. Because you're risking unneeded time for no benefit

Admittedly, all three of those are the same "equation", just the three ranges of where the numbers stand. But it's nice to specifically ask the first and third questions... because they can cut short the analysis.

[add-sub-mul-div]

It's very insightful to realize that the space of things that will go wrong or will be important does not overlap very well with the contemporary zeitgeist of warnings coming from "best practices" and industry "thought leadership." It took me a while to get there. It's just so easy to point to some blog post that's become popular and use it to support your point when the person who wrote it knows nothing about your situation.

[lwhi]

The engineer is wise to ask this.

Architectural decisions sometimes close doors and making future changes very difficult.

The only thing we know for certain is that change will happen.