The Three No’s of Software Development

December 27, 2017

Part of my job is to estimate and evaluate new features. Can I do X? What if we tried Y? Sometimes I have to tell a client “no”, but there’s always more to it. I don’t shoot down ideas for fun. Sometimes what they want to do sounds more interesting than the realistic options, but it’s not my job to make projects interesting for my team. I’ve discovered most “no’s” fall into one of three categories.
 

“Not Possible” No

This is the simplest one, but is often hard to explain. What the client wants is flat out impossible (or prohibited) at this time. Often times this means they want to use data that doesn’t exist or implement a feature that Apple doesn’t allow. Sometimes it has to do with low-level APIs that we don’t have access to. This can be tricky to understand for non-developers if they see someone else doing something similar (“Android does it!”). As much as I’d like to believe software can solve every problem, there are some things we can’t do today.
 

“Not Enough Money” No

My least favorite. Usually this means the client has come up with a crazy feature that would work well and be interesting to build, but I know they don’t have enough money for it. Developers are bad at estimating project timelines. Non-technical clients are terrible. And they should be, without software knowledge it all seems like a black box. Worse though, they have a habit of underestimating how long features take to build. It’s worth noting that most clients are respectful of this. Rather than try to pull more money out of them, we work together to find a solution.
 

“Not Practical” No

This is always a soft no. Actually, I rarely use the word no. I give some pushback and try to educate. That makes this the hardest no. A “Not Practical” No means the client’s idea won’t solve their problem or be cost effective. After working on a project for a long time, you get a good idea of how it works and sometimes you learn about it’s industry. Every once in a while a client comes up with an idea that won’t benefit them. Are you sure you want to spend tens-of-thousands on a mobile app? Is the responsive web app working well? Would that money be better spent adding new features? There could be dozens of reason they shouldn’t pursue an idea, but it always comes from desire to make the product as good as possible. Sometimes this means lost revenue if I dissuade an expensive idea because it’s not worth it for them. My hope is that each client trusts us to be an expert in software development and lean on our experience. But, it’s their product, and I trust they know the market better than I do.
 
Being impossible and being broke are easy to understand, which means being impractical is the most dangerous. There are always scenarios where one side is wrong about a feature, which makes is important to a) find a development partner that has experience you can trust and b) evaluate your product holistically. Don’t follow an idea because it is exciting; follow it because it’s valuable.