Why "It Can't Be Done" Is Rarely True in Software Development
A brief reflection on how a clear mindset and common sense can defuse almost any technical problem.
There's Almost Always a Solution
In my career as a software developer and IT consultant, I've learned: The statement "That can't be done" is almost always an indication that an important prerequisite is missing – not that the goal is unattainable. When a microservice supposedly doesn't scale, the view of backpressure, caching, or connection pools is often missing. When an API is "too slow," the look into the profiling tool is often missing.
Three Questions I Always Ask Myself
- Do I really understand the problem? Symptom ≠ cause.
- What assumptions am I making? Assumptions are the most expensive bugs.
- Who needs the solution when? Time-to-impact beats perfection.
Practice: From "No" to Solution Proposal
After a No, there must always be a solution proposal from me. This isn't a platitude – it's a work ethic that I instill in teams. It changes meetings, accelerates decisions, and makes engineering what it should be again: creative problem-solving.
"It's not rocket science." – most of the time it isn't.