[jasode]

>Whereas in fact any engineer worth her salt will tell you that she makes business decisions daily–albeit on the micro not macro level–because she has to in order to get the job done. Exactly how long should this database field be? And of what datatype? How and where should it be validated? How do we handle all of the edge cases? These are in fact business decisions, and we make them,

I would suggest that software programmers do not adopt that mode of thought unless they want to be disrespected by business people. Even with the author's qualification of "micro-" as in micro-business decisions, it still does not make the statement respectable.

I say this as a someone who's been on the business side and the hardcore software programming side. I think other engineering-entrepreneurs sympathetic towards programmers would also be dismissive of such proclamations trying to glamorize "VARCHAR(30) vs VARCHAR(40)" as a "business decision".

If software programmers want to be viewed as key business people, they have to make real business decisions and not dress up or redefine programming thoughts as "business decisions".

[ttctciyf]

(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.