How Non-negotiable Features Kill Software Products
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)