| I think this advice is a little vague and therefore easy to get wrong. My approach converged to something that can be understood as a form of progressive enhancement, so basically providing the simplest usable version of a given feature, bearing in mind that eventually you'll have to expand it to what was originally requested - but that's all in separate tickets. Some examples: Six different payment processors? Start with one or two. SPA frontend? Start with server-rendered. The tech is there to smoothly transition from one to the other, but it's possible that this will never be required. That colour picker shaped like a peacock, following the mouse with its gaze? Just use a regular colour picker, but make it easily swappable. Where's that in the requirements anyway? What's interesting is that more often than not enhancements lose priority in favour of new features. Meanwhile some universal techniques like preferring pure functions where reasonable, using immutable data structures and actually having an architecture take as much time as doing sloppy work and go a long way into ensuring maintainability. |
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.