> "Allow end users to programmatically configure widget xyz"
That's an extremely poorly defined requirement, and I would say that's the ultimate source of the issue. Your team took that and made a crud api. Another team might have written a YAML based DSL. Another team might have created an even more complex scheme.
A BA/PM should have pushed back on that and gotten much, much better specificity as to what the users needed to do.
> And to be clear, of those 50 fields, maybe 3 of them mattered to the end user and the rest could have been inferred. But doing that inference is a lot more work as it takes understanding the domain.
Exactly -- except the part about "doing that inference is a lot more work". Compared to recovering from the wrong path the software has taken?
That's an extremely poorly defined requirement, and I would say that's the ultimate source of the issue. Your team took that and made a crud api. Another team might have written a YAML based DSL. Another team might have created an even more complex scheme.
A BA/PM should have pushed back on that and gotten much, much better specificity as to what the users needed to do.
> And to be clear, of those 50 fields, maybe 3 of them mattered to the end user and the rest could have been inferred. But doing that inference is a lot more work as it takes understanding the domain.
Exactly -- except the part about "doing that inference is a lot more work". Compared to recovering from the wrong path the software has taken?