The unspoken assumptions behind scary phrases

There are certain phrases that developers use that mean something is underfoot that could jeopardize development schedules.

  • We want to make this dynamic so we don’t need to deploy code to change it.
  • The algorithm is not optimized, I’d like to take some time to optimize it.
  • When we were refactoring this component, it looks like it’s going to take longer than we think, and we’ll need to rewrite <x>.
  • The great thing about <technology x> is <feature that matters primarily to developers>.
  • We should use <framework x>, it’s the future. <Framework y> is dead. (examples: We should use React, Angular is dead (and vice versa)).
  • When we do <large thing x>, it will allow us to do <thing that business wants a short term solution for>. “If we move from SQL to a Document Database, we’ll be able to have faster queries in the future.”

All of these are perfectly normal things to say, in the right circumstances. But, all of them require business context and an understanding of business needs in order to be a “good idea”.

Here are those phrases with business context and developers assumptions built in:

  • “We want to make this dynamic so we don’t need to deploy code to change it, and we spend a lot of time deploying code for minor fixes. (The problem here is the deployment pipeline, and the assumption is they can’t fix the deployment pipeline or don’t know to, so they’ll change the code, because they understand that).”
  • “The algorithm is not optimized, I’d like to take some time to optimize it, because I believe it’s the most used algorithm and that shaving time off this business process will result in <value>”
  • “When we were refactoring this component, it looks like it’s going to take longer than we think, and we’ll need to rewrite <x>. We’ve known <x> has been a large problem for a while but we haven’t had the agency to fix it. We’re hoping you’ll let us because <x> is really bothering us and we believe it’s slowing us down from delivering <feature set y>, that you really want.”
  • The great thing about <technology x> is <feature that matters primarily to developers>. We don’t think it matters to you but we believe you may have ancillary benefit <y>.
  • We should use <framework x>, it’s the future. <Framework y> is dead. Framework X has been hard for us to adopt and we are having daily issues with it, and the public sentiment around <framework y> is better. We think it’ll solve these problems we’re having.
  • “If we move from SQL to a Document Database, we’ll be able to have faster queries in the future. We believe the business doesn’t need the ease of relational querying and since the customer doesn’t need reporting or querying, they just prefer to access business data directly by its key, we can move faster by not dealing with the relational database at all”.


In each, there are lots of unspoken assumptions about technology, the team, and the business direction whenever you hear one of these phrases. I’ve watched businesses chase their tail because these unspoken assumptions weren’t surfaced in time. Contrawise, with few exceptions, technology stack changes offer incremental improvement (if any) instead of evolutionary improvement. Act accordingly.

Junior vs. Senior Developers

Junior Developers are working on mastering the code, the structure, the system. They’re worried about whether they can even do the task they were assigned.

Senior developers are working on mastering the impact, the tradeoffs, and effectively communicating with business about issues and opportunities. They’re worried about whether they can effect the change the business wants.

Each segment will want to understand different aspects of the problem in detail. For Juniors, they really want a well specified problem. For seniors, they want a well specified goal and outcome.

Do the Short Film First

We know Pixar as the company behind Toy Story, but Toy Story wasn’t Pixar’s first film. Toy Story is perhaps its most memorable first feature film, but it wasn’t its first film. Pixar had five short films before releasing Toy Story in 1995. These shorts, although not revenue grossing themselves, were used to show off the technology behind Pixar, demonstrate their director’s ability to tell stories visually, and garnered experience for the Pixar team.

One of the continual Pixar traditions is to have up-and-coming directors to create a short film first and demonstrate that they can tell a story visually, and they still use Short films to show off new technology.

We tend to do things differently in software. It’s hard to get stakeholder buy-in for a small pilot first — something that ultimately may not even be folded into the project or product, but something that demonstrates either the technology, or the problem domain, or the team’s ability to build software together.

That learning and melding of a new team is critical to success. It’s not a stretch to say that without those five shorts, Toy Story wouldn’t have happened. If it took Pixar five short films to get their hit, what would it take for your team to hit a home run for your business?

You have a big idea and your team is working towards launching that big idea. Instead of trying to tackle the big hairy problems in that big idea, focus first on one of the smaller ancillary pieces. Your build pipeline, or a small web application that exposes a piece of it — whatever it takes to prove that your team can successfully launch the solution to that big and hairy problem.