During day-to-day software development, I have often heard developers say, “This is a business decision” when confronted with difficult choices. It could be a big decision about which hosting platform to use or architectural approach to pursue. Or it could be small, such as whether to build (more) monitoring capabilities or shave off 75 ms on a particular web request.
In all these cases, the decision made has to be informed by the resultant business impact. Unless we’re talking about a computer research context, software developers shouldn’t make choices on a technical basis alone. All the choices we make have consequences for the business context that we are in.
Some choices are no-brainers. Although we might be considered a young profession, decades of software development have engraved a number of best practices and collective knowledge that have proven to hold true in many applications. There are certainly lots of conventional (technical) wisdom to apply.
But many choices are not no-brainers. Making the right choice requires sufficient (not complete) knowledge of the application domain, applicable technologies, and the current tactical and strategic challenges for the business you are trying to drive forward. In making any decision there is a cost/benefit consideration for the short, medium, and long-term. There’s the estimating effort, effect on technical debt, user impact, and so on.
Software product development is a cross-disciplinary effort, bringing all players onboard to make complex choices. This often requires software engineers, product managers, user experience designers, visual designers, user researchers, and business domain analysts. Each professional brings their piece of the puzzle to the decision-making process. Everyone also needs to be aware of the tactical and strategical challenges and goals of the company. So certainly, since we are not developing software for the sake of developing software, any technical decision is a business decision — and a developer cannot make most of them alone.
Returning to, “This is a business decision,” my gripe is that it’s being used by software engineers to deflect the responsibility for making a choice. The phrase is put forward to implicitly mean, “This is not my business and not my decision.” Wrong! That is exactly when a software engineer needs step up and contribute in order to align with the business. She/he needs to be accountable.
Speaking as a software engineer, not only are we entitled to, but are also obliged to have an opinion on all software development related changes, given the business context in which they are made. This means taking in and understanding what the business context is and formulating an opinion that is articulated in terms applicable to the business. We need to make understandable what the consequences of a choice will have for the business.
Therefore: Stop hiding behind your professionalism. Form an opinion, and be vocal about it!
Tradeshift blog – Let’s build awesome stuff
Tradeshift blog – Sources of randomness in java