{{ !articles[0].partner.isSponsoringArticle ? "Platinum" : "Portal" }} Partner
agile,devops,project mgmt.,technical debt

How Non-negotiable Features Kill Software Products

You’ve most probably been there: To win that one ueber-important client, your friendly sales rep sells the farm and his grandmother (well actually he sells features, which he invents right in front of the client to make sure to get the deal, but the effect is nearly the same). And not only does he sell „the grand new feature in the sky“, but he even guarantees a delivery date – and all without speaking a word to the tech guys. Sweet, huh? He is a hero. He made that huge deal and everyone is patting his shoulder. Well, besides you probably. And everyone else who now has to deliver a completely bloated feature in a totally unrealistic time frame. And, of course, there’s absolutely no room for negotiations. In fact, you’re not even allowed to talk to the client to ask a question about his requirements because the sales guy doesn’t want to make a „bad impression“.

Creative Commons License Jo Naylo

Non-negotiable Features Create Technical Debt

You know what happens next. The developers scramble to their feet and churn out something, which, at first glance, can be considered as the feature the client ordered. You don’t have time for adapting the architecture to the new needs. And, of course, automated tests, proper feedback, and a useable UI go right out the window. You might be able to pull off that crazy delivery date, but at what cost? You’re left now with a bloated beast of software put together in such a rush that no one dares touch once it’s released because the chances of breaking something are significant. You dug your technical grave, but the rest of the company is celebrating a huge win! No one outside the tech department noticed how huge the technical debt you’ve just taken in order to deliver.

No-one Profits From Non-negotiable Features

If features are pre-sold without any option to negotiate what’s important and what may be left out, you inevitably end up with too much complexity. Sales representatives often feel pressure to promise too much to a client. They want to close a deal, but they’re not able to see the technical implications. They raise very high expectations and often fix them in the contract which removes any way to iterate and develop your product until it’s actually useful for your client. Instead, the contract is based on a rough, but very challenging scenario, which is impossible to deliver and has very little chance to fit the client’s needs once it is released. Such pre-sold features not only tie your hands, but the client is also not able to change what he needs over time. Both parties agreed to the contract and a rigid change management process is installed to make change as painful (and therefore infrequent) as possible.

Published at DZone with permission of {{ articles[0].authors[0].realName }}, DZone MVB. (source)

Opinions expressed by DZone contributors are their own.

{{ tag }}, {{tag}},

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}
{{ parent.authors[0].realName || parent.author}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks