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.

“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.}

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.

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.

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.

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.