In my weird role as hybrid contractor/consultant I get asked, “Is it possible to do {{some_feature}}
?” and what goes through my head is a bastardized version of the Apostle Paul saying:
All things are possible (with code), but not everything is beneficial.
— The Apostle Paul, principal engineer
The answer to “Can you make {{feature}}
with code?” is almost always “Yes.” Given infinite time, infinite budget, infinite lines of code, and infinite opportunities for failure; I’m almost certain we can come up with a working solution for any scenario you can dream up. There’s JavaScript in space, I’m sure we can figure out your idea.
Now does it work for the user? Would it explode the timeline and scope? Does it add an immense amount of complexity and technical debt? Would it tear the social fabric of American democracy in the process? Oh— those are different questions entirely but 100% related to code.
It’s difficult to describe the burden that one small change can add due to the opaque nature of code systems. They seem like sturdy black box assemblies, but — like everyone’s favorite analogy, LEGO — can have brittle parts that fall apart once touched. One of the most frightening people I’ve worked with in my career was a “yes-man” who would stay up and commit thousand line tomes of code to appease a manager’s pet feature requests. Big pieces bolted on to a brittle system with no plan to maintain. Small, unconsidered features are a timebomb.
Better versions of this question for me are:
- Is it possible to do
{{some_feature}}
by{{date}}
? - Is it possible to do
{{some_feature}}
for{{budget}}
? - Is it possible to do
{{some_feature}}
in a way that accomplishes{{goal}}
?
Oh, here we go. This may resolve to a non-yes answer. Constraints go a long way. Constraints are how we get to play. A game without rules would not be fun. Play is how we as humans adapt to an ever-changing world. With constraints we can play with the idea and figure out its potential. Unless there’s a backlog jamming up the timeline and adding pressure, you should be able to come closer to a correct answer.
But people don’t like non-yes answers. People don’t like options closed to them. I think this is innate and I see it in my children when they shut themselves in their room after I tell them “No”. “No” carries a stigma for the no’ee and the no-sayer. No one wants to be a wet blanket and I mean that —in a biological sense— we want to promote group unity by saying “Yes”. But in every business and productivity book I read, saying “No” is the ultimate mythical business powermove because it produces better results.
Because no one likes a “No”, I can already tell a negotiation is coming. The next ask is going to be, “Let’s do whatever’s easiest”… but that’s another post entirely!