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.

It's a common issue to see a company's sales team promise new features in order to close a sale. Many times these new features are still in development or are still being designed. Sometimes features are sold before the development team even knows about them.

If the customer understands the features are not yet implemented this can help guide the product's design. However, if the sales team promises these features with an uninformed time frame it can put significant amounts of stress on the developers who are charged by management to meet the deadlines.

Additionally, sometimes non-existent features are sold to customers as being either completed or near completion when development may not even be aware of the requirements yet (legal/ethical issues notwithstanding).

Is there a word or phrase that can be used to describe the uninformed/irresponsible/unethical applications of this practice?

It's similar to feature creep, but occurs before development or design.

share|improve this question

closed as not constructive by Robert Harvey, Jimmy Hoffa, Dynamic, JeffO, gnat May 6 '13 at 22:08

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

17  
Unfortunately, it's usually called "business". –  Corbin March May 6 '13 at 15:45
13  
"Chaos", "Disaster", and "business as usual" all come to mind –  Dan Pichelman May 6 '13 at 15:45
31  
"Monday". Alternatively, "Tuesday", "Wednesday", "Thursday", and "Friday". –  jcmeloni May 6 '13 at 15:47
5  
I think Feature Driven Development is the closest. –  superM May 6 '13 at 15:52
2  
fun, fun, fun! bullet-point engineering? (or a little later) vaporware? –  Lothar Krause May 6 '13 at 16:11

6 Answers 6

up vote 6 down vote accepted

Overly optimistic scheduling is the term used by Steve McConnell in his book Rapid Development. He also uses the term wishful thinking.

McConnell writes (with supporting evidence) that an overly optimistic schedule actually makes the project later.


I had a bad experience with schedule pressure once. A customer was unhappy with a timeline, even though it was in line with similar projects. We hired a contract programmer with the hopes of shortening the timeline. The customer added many more features. (There was no review of "hey, the project is taking too long, and now you want more features?") The contract programmer was not as good as we had hoped, and I spent lots of time fixing bugs and design problems.

I don't want to live through that experience again as much as I can help it.

Yes, you should look for creative ways to help the sales team and management meet their commitments. Sales pay your salary.

Yes, you should be politely and firmly speak up about unrealistic schedules. The schedule may not change, but you did what you could. You owe it to your management to give them your best professional opinion, even when it is not what they want to hear.

share|improve this answer
    
Thank you. The phrase "Overly optimistic scheduling" yields some interesting search results. –  Corion May 6 '13 at 18:58

"Normal"

Keep in mind that sales teams are there to ... sell the product you wrote. They are naturally adapting to client demand and selling features that their (and yours!) clients need. You actually want them doing this; it means that revenue is coming in the door and that your product is staying relevant to market needs.

I'll note that this can be related to vapor-ware, in which things are promised and promised but never delivered. But there's a nuance behind that term that's not applicable to your question.


It's only an issue when delivery schedules aren't clearly defined or when the sales team over-promises on what can be delivered. And while this creates stress for the developers involved in implementing those visions, ultimately it isn't their issue to resolve. Upper management and product development management needs to work with the sales management to define when features can be advertised for sale and what schedules can be committed to. Over-commitment tarnishes the company's image and is rightfully an issue for upper management to resolve.


Generally speaking, Developers (and Sales...) like to see a Design => Sell => Develop approach to sales and marketing. Development has an idea of what might be flogged to the potential clients and Sales has an idea of when idea XYZ could actually be delivered if the potential client is interested.

There are cases where you'll see Sell => Design => Build, and this path is more likely to cause problems for the development team. On the one hand, if the Sales team really understands the code base* then this can be an effective route to new contracts. On the other hand, there is a greater chance to over-promise what can actually be delivered in a reasonable period of time. Your question calls out some of the keys in determining how well this approach will work out.

*Yes, I know the cynical reply of "that never happens." But it can occur when one of the founders of a firm was highly technical and has moved into a role driving more sales. There is also whole branch of "Technical Sales" personnel as well.

share|improve this answer
1  
I'm not referring to the normal cycle of feedback, which I expect would include development in the discussion of the feature's feasibility and timeline (at least a little bit). Do you still think it's normal/good for sales to promise features - e.g. in the next version - before development is informed? I'm not sure how to clarify the original question for this distinction. –  Corion May 6 '13 at 16:02
1  
Development shouldn't be picking what new features go into the product. That's Marketing's & Sales' jobs. If you have both, there is tension between Marketing & Sales, but that's not Dev's issue. Dev should provide feedback to M / S on relative cost of new features, but M / S declare what's to be built. Sales shouldn't give firm time-frames without getting an estimate from Dev first. But that's a "shouldn't" and not a "never." Many variables are in play depending upon size of contract; scope of change; and time-frame to delivery. –  GlenH7 May 6 '13 at 16:09
1  
@Bobson by definition, a new feature is one that needs to be invented and does not exist yet. I'm not trying to downplay the requirements for communication between Development and Sales, but Sales' job is to bring in ... new sales. And that requires new features. –  GlenH7 May 6 '13 at 16:10
2  
@GlenH7 - It's a spectrum. If your software is a point-of-sale system, and the salesman promises it can also manage receiving new inventory, that's reasonable. If the salesman promises it can also manage employee hours, that's something of a stretch, but there's a connection there. If the salesman promises it can also allow you to monitor cell phone usage in your store, that's a whole different kettle of worms, and where I feel like the OP is coming from. –  Bobson May 6 '13 at 16:18
4  
"Keep in mind that sales teams are there to ... sell the product you wrote." But surely they're not selling the software you wrote; they're selling the imaginary software that your customer wants to buy... –  Ant May 6 '13 at 20:55

This is a kind of organizational anti-pattern. I've heard a few terms for this practice:

  • Sales-Driven Development
  • Sales-Oriented Programming
  • Coding by the seat of your pants

Although there's nothing fundamentally wrong with this, and occasionally it can be very good for the business, if over used, it degenerates pretty rapidly into a variety of well known problems: feature bloat, big ball of mud, magic pushbuttons, etc.

share|improve this answer
    
This seems to come closest to answering my actual question so far. –  Corion May 6 '13 at 17:43

My organization would call this violating safe harbor, or selling based on forward-looking statements.

Every press release and sales presentation comes with a safe harbor statement, which boils down to, "Make your purchasing decisions based on our current features, since we don't guarantee delivery on features that haven't been released yet." Our salespeople are obligated to never promise new features on any given date, and if they do, they do so in contradiction to the safe harbor statement.

share|improve this answer
    
Thanks. Hadn't heard of a safe harbor statement before. –  Corion May 6 '13 at 20:21

As you describe it, there is nothing wrong with this technique of selling.

It only becomes similar to feature creep when the sales team promise things that cannot be delivered in the time frame they promise them in.

When this happens, the software development process can often fall by the wayside, things must be delivered quickly, and this can lead to

  • bad code
  • bad design
  • not enough (or no!) testing

Sadly, this is very common.

share|improve this answer
    
Pardon the poor description. I've updated to clarify. –  Corion May 6 '13 at 16:18

The cynic in me wants to say "Consulting", but that isn't entirely fair, because there are many consultants out there who are honest.

It is incredibly common in software consulting to sell something you haven't built yet, especially if you are doing bespoke, green-fields projects. Many organisations sell consulting services around their product, which invariably include customizations or unique features (SAP, Microsoft Dynamics, Microsoft SharePoint, etc).

It sounds to me like you are facing the frustration that comes from having sales people who are too disconnected from the technical team. There are many ways to improve this situation, but one we are starting at my workplace is "learning sessions" where different people teach the rest of the team about their job. Developers can learn about sales, and the challenges therein; Salespeople can learn about the challenges of software development. Another technique is to have the salesperson sit with the people whose services they sell. It breaks down the "us vs them" boundaries, and encourages everyone to play for the same team.

share|improve this answer

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