Over the past few years, I’ve had the chance to talk with multiple designers about their work and what their environment is like. And perhaps I was naive, but I was surprised at the number of times I heard that they were told by developers that X feature they wanted to do was “not possible.” Then when I would ask more about the requirements of X feature, I would often be boggled by how simple the request often was. So that got me thinking, “Why are developers often so quick to say no to what designers want?”

To get a few of the obvious counter arguments out of the way, I’m going to be speaking purely from a front-end perspective since that’s my area of expertise; but I do think the sentiments in this post still apply to the rest of the field. In addition, I’m well aware of the fact that a number of things could be playing into a developer (or his team) being able to build X feature. Many reasonable explanations include:

  • No access or control of the necessary source code
  • System constraints from legacy code / poor architectural decisions made in the past
  • No scope, time and/or money

The Problem

That said, the statement I draw particular issue with is when developers say:

No we can’t do that.

Now, short of some outlandish feature request, I honestly find that statement to be absolutely absurd. When I hear that statement, all I hear is the unwillingness to devise a solution to bring a feature to reality. Sad as this is for me to admit, but I’ve run into and heard of enough situations where I’ve seen developers give what only can be called pathetic attempts to help designers and/or stakeholders accomplish what they want. They often just stick with conventional solutions that are common and conventional. If the feature is outside of that bubble, good luck. This often works well for them because:

  1. These solutions are often well-tested and quite stable
  2. So as far as a developer’s job goes, that makes it much easier
  3. Because most stakeholders and designers aren’t technical, it’s often difficult for them to argue back
  4. If something does go wrong, at least it’s not their fault since it is more or less “industry standard”

And this is wrong on so many levels because what developers don’t realize is that there are so many negative byproducts of this kind of behavior:

  1. Designers begin to see developers as adversaries instead of teammates trying to build the best possible solution
  2. Stakeholders begin to lose faith in their technology department’s ability to get anything “creative” done
  3. The company starts looking to outside vendors to do more interesting projects because the internal team just isn’t cutting it

The Solution

Surprisingly, the solution is actually quite simple. No it’s not to kill yourself trying to build every feature imaginable. Instead, we simply make a few modifications to the original statement to become:

Yes, that’s possible; but these are the trade-offs we must consider…

In other words, while you may have the technical expertise in the difficulty level of implementing something, you do not hold a comprehensive understanding of the business plan or strategy for the product. So instead of acting like some endgame boss for projects, have a discussion with your team so that you all can make a collective decision that is best for the product and company. After all, maybe they don’t mind that doing that one feature will take an extra month as long as they get what they want. If you try to cut them off at the knees though, they never get that option and the working relationship is hurt that much more as a result.

Remember that as developers we have a critical role in building things in order to make projects a reality. So instead of acting as a barrier, let’s wield that power responsibly and use it to enable peoples’ visions responsibly.