[llamaLord]

A lot of this comes down to poor product management.

A shitty PM sees problems like "when a guest at a hotel room completed {specific action X}, they want to receive a notification saying {specific message Y}".

A half decent PM will stop, step back, and ask "is there a meta-pattern here that I'm just not seeing yet", and realise the actual requirement is something like.

"When a guest at a hotel is the subject of any meaningful business event related to their booking, the management of the hotel want to be able to send them some kind of configurable, context-bound notification containing information about that event (ideally with some simple conditional logic to skip scenarios where the notification isn't relevant).

As an engineer, you're going to look at those two requirements fundamentally differently, and sure, the second one is maybe 3x harder to implement initially... But once you're 20x different "bespoke notification events" deep, you're gonna bloody wish you built the second option from day one.

Src: am Snr PM who sees teams get screwed by this type of bad PM thinking all the time.

[giantg2]

"A half decent PM will stop, step back, and ask "is there a meta-pattern here that I'm just not seeing yet", and realise the actual requirement is something like."

Not going to lie, this is the funniest thing I've heard all day. I've met maybe 1 PM in my entire career that actually thought that way, and that was at the beginning. The longer I'm here the more they seem focused on speed and metrics and less on the actual sysrem.

[mooreds]

What are their incentives? Are they switching off to another product quickly, or are they staying with this product for years/decades?

Do they get rewarded for long term thinking or short term results?

[giantg2]

Almost nobody gets rewarded for true longterm thought. Devs, PMs, etc aren't going to stick around waiting for a promotion, raise, or bonus for work they did 3 years prior. They want their comp now for the stuff they did this year, even though you won't see the true longterm outcomes for years to come.

[ttymck]

But "YAGNI" has completely brainwashed the mind of "the lazy developer" so option (2) is seen as "resume driven development"

[mooreds]

YAGNI includes time to fix things when YNI (you need it). YAGNI is not prematurely optimizing for complexity.

If a PM (or an eng for that matter) can justify the need for the complexity, either because they are extracting 2-3 use cases in to a generalizable solution, or they have 1 but know that 2-3 or more are coming real soon, then bring on the complexity.

It's a balance, for sure.

[andrei_says_]

I think both are valid, and in the balance. At about 3x deep we know there will be 20 or more.

[ivraatiems]

I agree with that. I think the rule of thumb is:

The first time you do it, just get the job done as described. The second time, look for ways the two might be similar, but don't spend a lot of time on it. The third time, generalize and assume there will be a fourth, fifth, sixth, etc. time.

In the example the top poster gave, the first time it was requested, I would just write up some code for triggering the notification. The second time, maybe there's a shared class (or whatever) for notifications with text passed in. The third time, now maybe we need the ability to specify notification text in config or DB or through user-triggered actions.

[giantg2]

Ideally, the business should have their processes defined before ever implementing them technically. So these architectural questions should mostly be addressable from the start. Knowing hoe the processes look upfront can actually lead to some wonderful designs rather than constant reactors. We had a system that we knew from the start would have multiple UI layouts for multiple workflows that shared mostly similar data. We were able to build the UI to dynamically build the pages based on the data.

[llamaLord]

To be clear, I'm NOT advocating for premature abstraction, as a PM I live and die by "rule of three" when making decisions re: "let's just quickly solve this one bespoke need", vs "let's think about this more systematically".

But customers will never tell you all their requirements up front, and it's a PM's job when hearing a need from a customer to take the time to figure out if it's a single unique stand-alone problem, or simply one instance of an entire category, the other 3687 of which your customers are going to come asking for the moment they realise it's a category of problem your product is able to help with at all.

[Tabular-Iceberg]

Perhaps it’s better to ask what will put the greatest cognitive strain on the developers.

Generally I want to program for the specific case first and hopefully make it so small that it doesn’t hurt to throw it away when the requirements change. But if the specific case means the whole team has to be burdened with a lot of really obscure hospitality domain knowledge, maybe it’s quicker and easier to build the abstraction.

[ttymck]

Right, this is why a bad PM is worse than no PM. "Just build this one use case, and since it's so simple, I promised it by nex week". Instead of digging deeper, as you suggest.