Vaporware

Standard

Ever since the dawn of the commercial software industry there has been vaporware. The concept of selling what you don’t have, in a promise to make it later (sometimes even used as a false promise that will get quietly swept under the rug)

In the ideal business you’d be able to sell what you have, build or expand the features you want. Then sell and promote the new feature to keep customers and secure new ones. That is the ideal at least.

The reality is, however, that most companies (at some time or another) will fall into the trap of selling vaporware.

They’re always plenty of reasons:

  • “For the price the customer is paying, it’s worth the investment”
  • “The customer isn’t particularly happy with the software, so it’s an attempt to stop them moving to a competitor”
  • “We are planning to do that anyway, the customer is just extra incentive”
  • “Saying our product does this will get us into a new market”.
  • “Guarantee selling”

The issue starts with how much like a flood gate selling one bit of vaporware can be. Starting with small features, moving to full modules and sometimes even new products. The amount of work grows, but no matter how big the pile of future promised software gets, it only becomes unmanageable once deadlines are introduced.

Having multiple customers sold vaporware delivered by a particular date is a recipe for disaster (Particularly if insufficient effort has been put into the proper planning and time estimation). Prioritizing the work becomes near impossible, usually resulting in the work that was next on the to do list getting pushed back or unrealistic goals being set.

From my experience developers usually get little to no contingency and sometimes requests for overtime. And in the rush to get it done on time, quality takes a nose dive. The amount of time I’ve seen a development team cover for the promises of other departments will always astound me.

To a point, selling vaporware can be balanced well enough. Keeping the customer accurately informed is the key. One (maybe more depending on size) future promises can weave their way in the pipeline without much issue or pressure on the development team.

So what can you do? Honestly? Not much. Selling vaporware isn’t necessarily a problem if managed correctly. Meaning customers know it’s vaporware and realistic timescales, if any, are set in place. As a developer you will probably not notice if this is the case. However if its badly planned. What do you do then?

  • Speak out. Don’t let the promised deadline effect how long you think it will take to do the work correctly.
  • Don’t feel obligated to do overtime. It’s not your fault it’s been poorly planned. And if you’re okay with doing the overtime, negotiate a good overtime rate. It is your personal time you’re giving up.
  • Talk to your managers and other developers about it. It could be you have the wrong end of the stick, or your managers are unaware of the undue pressure across the department as nobody else has spoken up.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s