The way I see it, my job isn't to just blindly implement what the business thinks they want. It's a two way thing. If a set of business rules are too complex and convoluted, I explain that this incurs a cost, in increased likelihood of bugs, and slowdown of future development. We then think about how we can simplify the rules, or reduce complexity elsewhere. In one such case, we agreed with the business to remove an entire feature, to make the new feature more robust and easier to develop. I deleted 1/3 of a codebase as a result, ultimately the overall complexity of the system was substantially reduced after the new feature. It was immensely satisfying.
This is where a good product team helps. Understanding the threshold at which technical debt would undermine a business feature. Glad that it worked out well in your case
Comments
The way I see it, my job isn't to just blindly implement what the business thinks they want. It's a two way thing. If a set of business rules are too complex and convoluted, I explain that this incurs a cost, in increased likelihood of bugs, and slowdown of future development. We then think about how we can simplify the rules, or reduce complexity elsewhere. In one such case, we agreed with the business to remove an entire feature, to make the new feature more robust and easier to develop. I deleted 1/3 of a codebase as a result, ultimately the overall complexity of the system was substantially reduced after the new feature. It was immensely satisfying.
This is where a good product team helps. Understanding the threshold at which technical debt would undermine a business feature. Glad that it worked out well in your case