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.

1st Factor: Accurate in Theory

When a developer provides an estimate, it’s usually quite accurate, derived from a history of similar tasks and projects, as applied now on the platform in question. If development transpired without challenges and unknowns, there would be no need for further multiplication, but this estimate tends to be generous on two points: (1) that any obstacles which arise can be overcome quickly, and (2) that the scope of the details can be foreseen.

A chaste estimate from a developer represents the time it would take to complete the task if they remained in an uninterrupted state of 100% productive time, all the time.

2nd Factor: R&B (Research/Refactoring and Bugs)

The second factor comes from a collective yet measured cynicism towards bugs. It’s never the bugs you expect that kill productivity, and so it’s hard to anticipate the cumulative damage they will cause a schedule.

Estimates often overlook the research necessary before implementing new technologies, techniques, or integrating with other services. Every developer will invest time in researching an optimal approach for any number of project scenarios that require such analysis, but it’s easy to overlook the process in the course of initial estimation.

Combined, research and bug hunting/refactoring out of unfeasible solutions should at worst grow to the size of the normal development schedule itself, hence the multiplier. It’s a guard limit which, should you reach, you know your project’s in trouble, but if you don’t, then you understand as a natural appendage of development.

3rd Factor: The first 90% and the last 90%

This is about overlooking details which enlarge the scope of a task from beneath. When estimating, it’s easy to mentally do class modeling or construct a theoretical workflow or protocol, but it’s difficult to envision the extent of scaffolding that will be needed to facilitate the actual task. This will take the form of helper functions, refactoring and code hygiene, design improvements, and so forth, and are the tale of elegance and quality a good developer brings to the code.

As developers we sense the presence of this work, but during the estimation process it’s much more natural to think from higher levels of abstraction without realizing what’s required to build that abstraction in the first place.

This factor also represents the strange heuristic that developers must complete 90% of a project twice before the project is really complete. When an irrational exuberance starts signaling in the back of our mind that we’re only a few methods and tests away from delivery, we can recognize this as an emotional vanguard meaning we’re, in fact, approximately halfway from having actually completed our work.