Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
19  
In programming, anything is possible. Just remember that "Yes" is not an answer to "How long will it take?" –  Steve Evers Oct 8 '12 at 19:23
9  
@SnOrfus: Some problems simply can't be solved. If you think otherwise program a weather forecasting routine that will tell you if we will have a white Christmas. –  Loren Pechtel Oct 8 '12 at 20:07
5  
@Earlz: that's assuming that the universe is deterministic, which isn't necessarily true. –  whatsisname Oct 8 '12 at 20:47
4  
Sorry, impossible. The weather becomes chaotic after seven to ten days. There's a very famous paper on the topic, “Predictability: Does the Flap of a Butterfly’s Wings in Brazil Set Off a Tornado in Texas? by Edward Lorenz. –  David Hammen Oct 9 '12 at 0:23
25  
If the programmers are going to make promises they can't keep, what are the sales people going to do? –  JeffO Oct 9 '12 at 20:16
show 8 more comments

8 Answers 8

up vote 17 down vote accepted

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?

share|improve this answer
2  
+1 I didn't look over that list linked earlier, good job for pointing out there is some truly awful advice in there. The guy may be a good developer I have no idea, but he's certain he is which isn't generally a good sign along with this advice reads like it comes from some monthly IT-for-managers rag. –  Jimmy Hoffa Oct 9 '12 at 1:22
    
+1 - I never say "No" to customers (unless I don't want to see them again) - It's always along the lines of "It will cost X dollars", "Your technology stack does not support that" etc.. "No" closes the issue dead. use responses that open it for further discussion. e.g. "...but I could give you 90% of what you want for 10% of the cost" or ".... But I could implement it this way and give you a solution that works this way...." –  mattnz Oct 9 '12 at 20:06
1  
@mattnz - It's tough to say "No", but sometimes it's needed. "Can you get that change done by tomorrow?" Well, no. But I can get it by the end of week. "Could you do a Monte Carlo analysis with each these several hundred control variables varied randomly per run?" That's the one that garnered the "in which millennium do you want the result" response. I discussed the curse of dimensionality and suggested we pare that list down to something reasonable. How you say no is important, but you do sometimes have to say no. Diplomatically, of course. –  David Hammen Oct 10 '12 at 15:02
    
A 10% fail rate would be a MASSIVE improvement over the current average software delivery success rates. –  Graham Oct 16 '12 at 15:24
    
Regarding the airplane landing analogy - Planes are landed safely every day. If I'm a pilot and I respond "let me get back to you on that" to the question of whether I can land my plane safely, that isn't going to buy me any karma with the passengers. Even if I know there is a small chance of a landing mishap, this is a good example of where displaying confidence in my abilities of a pilot is more important than focusing on the small chance of failure. –  Cliff Nov 3 '12 at 16:32
show 1 more comment

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.

share|improve this answer
17  
It's often better to make sure a client tells you what problem they want to solve.. rather than have them go on a big spiel about the solution they want. Get the problem.. and tell them the solution. –  Simon Whitehead Oct 8 '12 at 22:11
    
+1 and more - two very good points you make - Never say "No", and do not lose credibility with you customer. –  mattnz Oct 9 '12 at 20:00
    
+1 "The customer will respect you if you are honest". That statement is so true and worth gold. When presenting options to the customer be honest. Simply tell them that what they are asking for is not some pre-built widget you can buy and plug. Let them know they are asking for a custom built solution and custom software is very expensive. This usually causes one of two thing to happen. 1.) They want a cost effective alternative. 2.) They are willing to pay for the custom solution. Either way it's a win/win. –  Cape Cod Gunny Nov 3 '12 at 19:56
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
    
+1 for referencing a code of ethics for answering a question about ethics. –  Jay Elston Dec 17 '12 at 20:57
add comment

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.

share|improve this answer
1  
that's the best way to... make users unhappy. More often than not, this will lead to profits shrinking –  gnat Oct 16 '12 at 13:25
3  
Honestly, for some In-House developers, this isn't a terrible idea. In-House work is usually not billed directly (IT is just part of the general budget) and you can get overwhelmed with crap requests because the requestors aren't out any money by spamming you with work. –  Graham Oct 16 '12 at 15:32
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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:

  • Confident they can deliver on all requests
  • Result: 90% of requests delivered
  • Customer is pleased that the contractor gave 100% effort
  • Customer perceives that the uncompleted requests were due to unforeseen issues, which probably outside of the contractors control

Contractor B:

  • Commits to delivering on 90% of the requests. Not confident they can deliver on the remaining 10%
  • Result: 90% of requests delivered
  • Customer is disappointed that the contractor didn't try to complete the other 10% of its requests
  • Customer assumes that the uncompleted 10% of requests were due to either lack of effort or ability of the contractor

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.