9 Ways Developers Fail to Accommodate Business
Developers tend to advertise themselves, indeed, their entire profession, as a pragmatic yet sophisticated participant in business, creating real human value while neatly abstracting away the complexities of technology. They often see themselves in opposition to other participants, engaging in heroics, or protectionism, or just toiling unsung for the higher good.
It’s a flattering portrait that manages to combine superiority, rationality, and integrity in the developer’s character, appearing all the more inviolable when compared to abusive, thoughtless management or the gasping demands of the customer.
These are gross straw-men, however. Even if, as developers, the relationship between business and technology, between corporate and creative, places us under the thumb of clueless decision makers, and even if those authorities are wielding capricious power that can entangle and maim a project, we still have much to answer for ourselves, nor are we as martyred as we like to believe.
If management abuses power, then developers abuse knowledge. It’s around this fact where developers most often fail to support business needs and the “outsiders” who control them. We act as the privileged gatekeepers for warrens of technological complexity, and it’s our responsibility to examine, understand, distill, and communicate the features and tradeoffs of these systems. When we hoard knowledge, saturate our colleagues with irrelevant details, or refuse to take responsibility outside of our technological boundaries, we fail business.
And it’s not always a failure of omission or laziness, because by deliberately hiding or revealing technical facts, developers have the power to steer business decisions and often use this power to a greater or lesser degree in fighting back against perceived corporate hostilities or mistakes. Such influence may be well-meaning or even necessary, but often it’s the result of tensions appearing in a project or a developer who miscalculates their role.
With that said, here are some of the ways that developers fail their businesses.
1. Justification Fail: a failure to rationalize our technical decisions to others and adequately explain our decision making process. As much as software development is about managing tradeoffs, it’s important that we remain aware of the reasoning behind founding technical decisions we make, and likewise important to be able to account for our rationale to laymen.
2. Dependency Fail: a failure to understand, lucidly explain, or else explain at the right moment the deep dependencies between technical components, and the ramifications these relationships impose on system design or change requests. It’s the absolute responsibility of the developer to inform others when outside influence is threatening a dependency such that subsidiary work will be required or other unintended consequences may occur.
This is one of the most serious fails a developer can make, since we’re normally the only individuals with a clear understanding of a system’s composition and behaviors and the ways these drive each other. We’re also a vanguard, expected to remain vigilant to dependency problems that emerge in the course of development, and only we have the power to alert the team to forthcoming dependency tension or else fail to do so.
3. Transparency Fail: Due to the arcane nature of development work, it’s easy for our habitual work efforts to become unintelligible, maybe even invisible, to outsiders. It’s our failure that we don’t make some effort to communicate our activities at a high level, so that colleagues feel everyone is moving forward together.
4. Scheduling Fail: a common failure, partly due to the nature of software development, but also because developers are prone to confusing known and unknown elements, or mistaking the later for the former. When estimating development schedules, we ought to provide solid estimates for tasks of known scope while allowing for sufficient leeway in undertaking tasks of unknown scope.
5. Knowledge Transfer Fail: accumulating vast reserves of formal and informal intelligence about a system, developers often fail to share that knowledge, and become human silos for some of the most core competencies of a company. A developer should be to some extent documenting their design and decision making process in respect to current development work AND to how it may impact future development. Transferring knowledge means allowing other developers to quickly adopt the insights and proceedings you’ve recorded, while failing to do so means making yourself both an essential resource but also an extreme liability.
6. Platform Fail: a failure to select a platform or implementation for ANY reasons other than it’s inappropriateness to the project on hand and direct development productivity. Playing favorites with technologies is a selfish and chauvinistic fail, and developers ought to be expected to learn new platforms when it makes sense to do so, and to evaluate them so they recognize that sensibility in the first place.
7. Security Fail: while security is often overlooked by all sectors of business, a developer should always be passively aware of vulnerabilities in the systems they command, and go out of their way to ensure that even if these aren’t addressed that the risks and consequences are understood by everyone accountable. Only a developer can evaluate this accurately, so they must be a vocal advocate of security (or lack thereof) awareness.
8. Priority Fail: failing to prioritize workloads based on productivity, business requirements, or known scope is inimical to a project. Approaching development on the basis of personal or professional interest undermines the already fragile development cycle, and is by contrast a demotivating factor when it comes time for the priority work to be tackled.
9. Social Fail: there are plenty of fail-heavy stereotypes about developer personalities, and they aren’t worth rehearsing because by social failure I don’t mean likability, but rather failing to integrate with a team, as if you yourself were some closed social format and the rest of your office was talking in open source protocols.
I wouldn’t call unfriendliness or cynicism a fail, but not sharing your insights and teaching things to your team, not advocating for best practices or introducing ground-up improvement in your team’s spoken or unspoken development methodology, refusing to support incidentally related issues with your expertise, neglecting all efforts to advocate richer and more interesting possibilities for technology, and proudly shunning compromise during interpersonal conflict, these all constitute grounds for social failure where a developer, a considerable repository of knowledge and opinion, neglects to participate in their community or decides that other humans must implement implement their jobs to the developer’s “proprietary, social specifications”.
However true it is that development is often scapegoated, mistreated, distrusted, overruled, or abused by Corporate Masters, this shouldn’t be cause to retreat from a wider prospective or shut ourselves off to the subtle or reactionary or purely unintentional ways we fail to contribute larger project goals. It should never be an excuse for our own incompetency or negligence, and I think the developer community would be much better served by relaxing some of its criticism of other vocations and tightening the criticism of its own habits.
Software projects rarely fail for technical reasons, but developers tend to accept this as evidence that they have no done wrong, when they are just as human and answerable as anyway else involved. Our value as developers derives heavily from our wisdom, insight, and expertise. When we miscalculate the importance of that, or selectively use it to exert control, we are failing the businesses, and people, that we are supposed to help.
