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.