It's complicated

Throughout my career, I have worked with developers who resist adopting new technologies. Their default response to anything unfamiliar is the same: "it's complicated."

Some of these people hold senior positions -- team leaders, CTOs, even CEOs. That makes the problem worse, because their resistance trickles down to the entire organization.

The phrase "it's complicated" is one of the most useless statements in software development. What does it actually mean?

#The definition of complication

Consisting of many interconnecting parts or elements; intricate. Involving many different and confusing aspects. Cite: Oxford dictionary (https://en.oxforddictionaries.com/definition/complicated)

#Redis, an example of the "complicated" label

You are working on a web project. Every HTTP request triggers multiple database queries, and the site is getting slow.

After investigating, you determine that a caching layer is the right solution. Your research leads you to Redis -- the most widely used in-memory database for caching.

You bring this to a colleague -- let us call him Parker -- and he immediately pushes back. Redis is "too complicated," he says. He has never used it.

In reality, Redis is one of the simplest databases you will ever encounter. It stores key-value pairs. It has a small command set. You can learn the basics in an afternoon.

So why does Parker think it is complicated? Because he confuses unfamiliarity with complexity.

#Complication vs Knowledge

There is a significant gap between what people perceive as complicated and what they simply do not know.

Not knowing something does not make it complicated. It means you have not learned it yet. Those are fundamentally different things.

Parker has not taken the time to understand what Redis is or how it works. Instead of admitting that and spending a few hours learning, he labels it "complicated" and shuts down the conversation.

Software development is continuous learning. If you are not willing to learn new tools, you are in the wrong field.

#Complication vs Conservatism

Some developers stop learning after university. They are comfortable with what they know, and anything outside that comfort zone triggers resistance.

This conservatism leads them to reject improvements reflexively. Even something as straightforward as Redis can cause panic.

The strength of software development lies in exploration and experimentation. If that makes you uncomfortable, you need to adapt -- not hold your team back.

Parker needs to listen to his colleagues and actively seek opportunities to grow.

#Arrogance and ego

Some developers oppose solutions they did not come up with, regardless of merit. They believe they are the best in the room, and any idea from someone else is a threat.

In some cases, this crosses into resentment toward colleagues with deeper expertise. It happens more often than you would expect.

Software development is collaborative. We learn from each other. We build things together. Ego and resentment poison that process.

If you find yourself opposing a tool or approach because someone else suggested it, check your motivations.

#The right tool

Redis -- or any technology -- is not always the right answer. You should always evaluate whether a tool fits your specific problem before adopting it.

The issue is when "complicated" becomes a blanket dismissal that kills all discussion. Companies that do this end up stuck on outdated systems while their competitors move forward.

Parker should not blindly adopt Redis. But he should evaluate it honestly. He should discuss the trade-offs with his team and make an informed decision rather than a reflexive one.

#Summary

• "Complicated" usually means "unfamiliar" -- not knowing a technology does not make it complex; it means you need to invest time learning it.
• Software development demands continuous learning -- if you stopped growing after university, you will struggle in this field.
• Conservatism kills progress -- rejecting new tools reflexively holds your entire team back.
• Ego has no place in engineering -- opposing ideas because they came from someone else is destructive to teams and products.
• Evaluate tools honestly -- do not dismiss technologies without investigation, and do not adopt them without evaluation.
• Leaders set the tone -- if you are in a senior position, your resistance to learning will cascade through the entire organization.
• Trust your team -- listen to your colleagues, encourage their input, and create an environment where people can do their best work.