In an article from HN, I came across the following advice:
Always tell your customer/user "yes", even if you're not sure. 90% of the time, you'll find a way to do it. 10% of the time, you'll go back and apologize. Small price to pay for major personal growth
But I've always thought that one should do a feasibility analysis before making any kind of promises to a customer/user, so that they aren't misled at any point. At what circumstances, then, should the above advice applicable?
It would be better to say "I think that can be done". or "I'll check and get back to you". I've had times where I've said no or counter proposed something. If the customer wants "a browser based application that works without ever being connected to the internet and uses tactile feedback", it probably is possible. But it is expensive and it would be more useful to discuss what the actual needs are.
The customer will respect you if you are honest. In the advice in the question, the person is wrong 10% of the time. If I work with someone who is routinely wrong one out of every ten times, I'm not going to trust him/her at all. That's a horrible track record.
This is the second question in short succession triggered by that article.
Good programmer: I optimize code. Better programmer: I structure data. Best programmer: What's the difference?
There's another name for this: premature optimization.
Never use early exits.
That's the "single point of entry / single point of exit" rule. It's a patch over the real problem, which is that exiting early might leave a mess. The right rule is "clean up your mess". An even better rule is to use data constructs that clean up after themselves so the programmer doesn't have to worry about cleaning up their mess.
And now, Always tell your customer/user "yes", even if you're not sure. 90% of the time, you'll find a way to do it.
This too is incredibly bad advice.
Sometimes your customer needs to be told no, or "in which millennium do you want this?" Don't promise something that will destroy your architecture, that will cost far more than the customer is willing to spend, or that you don't have a clue toward how to achieve it. You know the technology, not the customer. If you don't know how to do it, don't say you can do it. If you aren't sure, say you need time to research whether it's possible. It's better to be honest, and it will keep you out of trouble.
Customers quickly become ex-customers if you can't deliver on your promises. A 10% failure rate might sound small, but it is that 10% your customers will focus on. Sometimes they sue when you fail to deliver on what you promised. You really don't want that. Other times, making sure you do make good on a promise can make you go bankrupt, go insane, or lose your spouse because you're working 18 hour days. You don't want that, either.
Think of it this way: What do you think would happen to the airline industry if 90% of all airplane landings were successful? Do you think going back and apologizing for the 10% that crashed would fix anything?
This question has been studied formally and is addressed by the jointly produced IEEE Computer Society / ACM Code of Ethics.
2.01. Provide service in their areas of competence, being honest and forthright about any limitations of their experience and education.
3.04. Ensure that they are qualified for any project on which they work or propose to work by an appropriate combination of education and training, and experience.
3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates.
5.05. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work, and provide an uncertainty assessment of these estimates.
There are certainly business and legal implications about promising something that you can't deliver. Usually these come from the customer going elsewhere, refusing to pay, or suing your company. If you are in a partnership with others, they may sue for damages if your part is not delivered. Lawsuits can even come from competitors.
There is a story from the early days of supercomputers where Seymour Cray and a team at Control Data Corporation were close to launching a product, and another very large computer company told its customers that it also was close to launch. The lie cost CDC a lot of business and turned into a lawsuit where the big company could not show any credible evidence for their claims. The result was what was at the time a big settlement worth $80 million dollars 1970 (about $223 million in 2012, adjusted for inflation). You can read about it here:
http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing
Promising the moon and delivering a rock is a sort of sales-man approach which should not be tolerated. If you don't know if it's possible, research it. Or, give them a quote on the amount of time you will have to take to look into it. This way you're not promising anything you can't deliver, yet you are being paid for the time it takes you to look into it.
Given enough time, resources and flexibility around the definition of success anything is possible. The white x-mass example is easy if you only want better than 50% accuracy and you have the user's geographical location and a little bit of statistical data.
The real first question in most projects is not if something is possible, but if it is reasonable given a certain set of circumstances.
Does the feature adds enough value to warrant the expense of the attempt?
Even if the idea would be pretty awesome, if it requires a long development period or the acquisition of some more exotic hardware it would be better for the client to know that up front and then steer the conversation back to more reasonable goals in most cases.
If someone is crazy enough to give you a blank check and no deadline then by all means tell them everything is possible, just let them know you have to invent & distribute several of the technologies involved in reaching the goal along the way.
On the other hand, when dealing with reasonable clients with reasonable resources there is sometimes nothing worse than telling the client some feature has to be cut after you have agreed to it because they may have already run off and spent time/money/resources promoting or documenting it and that 10% might have been the thing that got the project greenlit in the first place. Fall into on of those situations and you have just lost a customer, and more than likely gained a very verbal bad reference in an entire market.
Playing devil's advocate
Being of an analytical mindset, technical folks can tend assume that their performance primarily will be judged based on a scorecard of completed vs committed requests, but in practice, it's not as cut and dried.
Before development even begins, customers start to form opinions on a team's performance based on their level of confidence and willingness to commit.
Part of the reason for this is that customers can have a difficult time assessing whether a contractor's hesitation to commit is due to the sheer difficulty of the request or lack of ability of the contractor.
As there are no absolute criteria for measuring difficulty of a request, often what is more important to the customer is trust that the contractor is giving 100% effort, rather than whether 90% or 100% of the requests are met.
Suppose the customer has to choose between two scenarios:
Contractor A:
Contractor B:
In both scenarios, the same number of requests were delivered; however, the customer felt that the "overcommitting" Contractor A was giving 100% effort and used this to validate that the remaining requests truly were difficult, to Contractor A's credit.
On the flip side, the customer felt like Contractor B wasn't giving 100% effort and its inability to complete all of the requests was either due to Contractor B's lack of effort or ability.
Disclaimer: I am not advocating overcommitment as a strategy; this is just an observation of a possible real world situation in which overcommitment might have positive results.
You should tell them to give you time to create an "spike solution".
A spike solution is a small program that, in coding it, allows you to figure out how to do, or even whether it is possible at all, something that is creating uncertainty in a project.
For example, suppose you have never send SMS programmatically, but somehow you know it's possible. A spike solution would be to make a small program that sends a SMS. That way it is no longer an uncertainty and you can make further estimates on feasibility.
Here's what eXtreme Programming documentation says on it:
Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build the spike to only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story's estimate. When a technical difficulty threatens to hold up the system's development put a pair of developers on the problem for a week or two and reduce the potential risk.
According to my experience, when a user requests something, you should ask them for a detailed specification of what the user really wants or needs. More often than not, you will never hear about the request again.
