[remon]

Your examples are very reasonable, and somewhat at odds if what the author is advising I think. As you say the advice is vague but I suspect it's also just fundamentally flawed.

There are very few real world scenarios where "just make it work" is a good approach to tackle engineering problems that require senior developers (read; developers with extensive experience in the related problem domain) in the first place.

My approach, which is I suspect it similar to what you're describing, is to define functional contracts first. Making them work is actually pretty low on the priority list, since that's consistently also the easiest thing to get right.

The hard part is correctly defining expected behaviour, interfaces and so on. In your example the hard part is constructing an interface/API for a payment processor that satisfies your business needs on the consuming side and is reasonably implementable for the relevant major payment providers. Actually implementing one, the making it work bit, is just not where the senior expertise adds value.

Unless, of course, you enjoy shipping glorified POCs to your customers because your stakeholders "saw it work" and blissfully ignored the metric tons of tech debts you just introduced, not to mention a skewed perception of the amount of effort needed for a that deliverable.

[Tade0]

The whole reasoning behind my approach is that stakeholders have needs and wants, but unfortunately these two get mixed up in communication very often, so to uncover which is which one must pit ones against the others. To this end every task is split into a "need" part and a "possibly not need, only want" part, with the latter later weighted against the "need" part of the next task.

Sort of insidious, but stakeholders are happy because they get their needs catered to in a timely manner.