| (Disclaimer: didn't read the article, just a response to the comment above.) I agree that db field definitions are not "business decisions", but "edge cases" can be. I think the trick here, as a programmer, is to realise when the different ways to handle edge cases of a design you've been asked to implement do become in effect business decisions, and then not make these decisions but instead push back and insist the decisions are made by the business whose logic you are implementing. This can be hard work a) to make the product owners understand the significance and b) to get them to commit to a decision, when often at heart they'd rather you just "make it go away." But it's much better in the end to be confident that corner cases and unforeseen consequences of a design have been ok'd with the decision makers whose actual job it is to make these decisions. Rarely, but sometimes, you can open up or bring into view aspects of a product design or business process that no-one suspected even existed like this, as a side benefit. This is from the point of view where there's a "separation of powers" between tech and product teams, of course. If you work in an environment where that isn't the case then you work with whatever process you have to make these decisions. |