If I Say “No” to Your Project
Like everyone in my profession I get approached by folks who are interested (or at least potentially interested) in hiring me to turn their business vision into a live, working web application.
If all of the maxims of self promotion (the vital importance of networking, having strong references, keeping clients happy so they’ll continue to hire you, etc.) are true (they pretty much are), it is of course in my best interest to say yes to any project that (a) I’m qualified to do, (b) I’m available to do in the called-for time frame, and (c) my price is acceptable for.
Saying “no” based on any of these criteria isn’t terribly interesting as most everyone holds to those three prerequisites for accepting work (though based on the regularity of client horror stories with their past vendors, it would appear that a lot of folks in my profession relax a little on point (a), but that’s for another essay).
What’s more interesting is saying “no” to a project when, by all conventional measures, it amounts to good, gainful employment while providing a client with what they know they want. I do this now and then, and I do it specifically when deep down I don’t believe in the project. When yes, they’ve got the money and yes, they’ve got the drive and vision enough to pull the trigger, yet I can’t wrap my mind around how this is ever going to work in the envisioned capacity. This is when my conscience pipes in, objecting to thought of taking money for a project that I don’t believe will ever bear fruit for the individual or organization willing to pay me.
Am I fallible in my estimations? Absolutely. I don’t pretend to know for certain how things will turn out. But I have done enough projects that had a lot of heart and a compelling vision which turned out to be ultimately a poor idea (and in hindsight could have been recognized as such with knowledge available at the start). For it I can recognize hints of blind optimism when I see them. Red flags of assumptions or impending obstacles that are unaccounted for jump right out and insist upon careful consideration before I can dismiss them.
This, while perhaps annoying as rain on someone’s parade, I believe is to everyone’s benefit. My being unwilling to take a client’s money and diligently complete the work when I can’t get behind a project might be the most generous bit of consulting I can give when confronted with a flop1 If I send you back to the drawing board because I think the project has major weaknesses2, I might well be viewed as insolent and unworthy of hiring in the first place. But deeper than that, I might well be doing you a huge favor, helping you to either (or both) save a lot of money & time, and refine your ideas so that they do ultimately succeed once a guy like me is brought in to bring it to life.
Though it breaks my heart to turn down good gainful employment, I do not hesitate to render this favor when appropriate.
By corollary, if I’m excited by your project and think it has legs, I’ll tell you as much and (if you care to hear it, most people do) explain exactly what specific merits I see it having and why.
There’s probably a good litmus test in all of this. Useless flattery to lobby for getting a contract is bankrupt. If you wanna sense for how much your success matters to your developer, throw a deliberately terrible idea their way and see what they think. Whether they they greet it enthusiastically or balk at it, ask follow up questions and you’ll really learn something about who you’re talking to as a service provider.
If I say “no” to your project, take it as a sincere gesture of commitment to its success. My doing so might either help you dodge a bullet, or prompt you to retool your vision in a massively useful way.
This is Programmer for Hire, a series of essays and explorations on the art of being a great programmer doing on-demand custom software development.