A Developer Who Always Says Yes Is Dangerous
A developer who implements every feature exactly as requested without asking why may appear easy to work with.
The stakeholder explains what should be built. The developer agrees, estimates the work, and begins implementation. Nobody has an uncomfortable conversation.
But this is not automatically good service.
It can be dangerous because a requested feature usually contains two different things:
- The outcome the business needs
- One proposed implementation of that outcome
The stakeholder often understands the first better than anyone else. The technical partner should bring judgment to the second.
The patient knows the pain, not necessarily the treatment
Imagine visiting a doctor and requesting a specific medicine.
You know the outcome you want. You want the pain to stop.
A good doctor does not ignore that outcome or take control away from you. But they also do not prescribe the requested medicine before asking what you are feeling, what caused the problem, and what the medicine would actually treat.
You went to the doctor because their judgment should improve the treatment decision.
Ask why before estimating how
During Creative Database meetings, stakeholders sometimes request a feature and describe how they imagine it should work.
The fastest response would be to say yes, write down the implementation, and send it to the team.
Instead, I ask:
- Why do you want this?
- What are you trying to achieve?
- Who needs it, and what should become possible afterward?
These questions are not resistance. They separate the real requirement from the first proposed solution.
In one conversation, a request initially sounded like a completely new feature. After understanding the outcome, we discovered that the system we had already built supported most of the required behavior.
Only a few additional lines of code were needed.
Blindly implementing the original request would have made Creative Database pay for a larger feature, wait longer, and carry more complexity for the same business outcome.
Use the existing product before adding another mechanism
A team that lacks context may create a second mechanism for something the product already knows how to do. The new feature then duplicates behavior, creates inconsistent rules, and becomes another part of the system that must be maintained.
That is why understanding the existing product matters before estimating a new request. Sometimes the right result is a new feature. Sometimes it is a smaller change, a different workflow, better use of an existing capability, or no software change at all.
Fast experimentation comes from understanding the goal
Creative Database described working with Codisar this way:
“We received a lot of value early on in our startup with quick turnarounds and the ability to test out ideas. As we enter a more mature stage in Creative Database, we are looking forward to further develop our relationship within tech, creativity and business together.”
