“The willow submits to the wind and prospers until one day it is many willows—a wall against the wind. This is the willow’s purpose.”
Frank Herbert, ‘Dune’.
Build to Customer Requirements. Nothing more or less.
Remember the Microsoft Kin phone? It was an acquisition from an external company. The business model to be a low cost alternative feature phone with always online connectivity during a time when smartphones were out of reach to teenagers and price concious adults. It supported a fixed set of social media applications to reduce network connectivity usage enough to negotiate highly discounted phone plan rates.
It was a huge flop. A huge financial loss. Effectively canceled within days of release. What happened?
Rumor has it they had the product ready to ship a year earlier. But the phone operating system was not using the Windows Phone kernel because it was a third-party creation up until that point. The team delayed shipping for a year until they could port everything over to the Windows Phone kernel. To no benefit, other than the promise that the team would be so much more productive in the “future” due to shared codebase with Windows Phone.
The future never came. A year later, smartphones and data plans were more than affordable to not need a specialized Kin phone. Back then in America (less so now) the network providers sold all the phones in their stores and locked to their network. They set the final price for the phone and data-plans the customer would pay. Network providers were, rightfully, upset at the delay. They priced the phone at non-discount rates. Who will buy a more expensive and outdated device with reduced functionality? The in-store staff were not trying to sell the phone over other devices. Product dead on arrival.
Please don’t build an extremely expensive product “feature” for the sake of the engineering team, at the consequence of the customer and your partner network. The Smartest Developers build the product for the customer, not for their own technical enthusiasm.
Counterpoint: Quality is Free
This counterpoint is an exception to the rest of this chapter. Sometimes exceptions further emphasise a rule instead of negate it.
Although, software (and all products) are only required to be built to the level of quality demanded by the market (and the customer), it is often advantageous to not stop there. To improve the quality of a product to the level the master craftsman/craftswoman can be proud of pays off dividends in gained productivity through less cost for maintenance and rework.
This concept was popularized in the 1980 book titled “Quality is Free” by Philip B. Crosby. Unfortunately, almost no one has actually read the book further than the title so it has led to confusion among thousands of engineering managers and project managers. The common misunderstanding is that they believe that if “quality is free” then we can reduce delivery timelines to the bare minimum to ship a barely functional product as quickly as possible. If there are any bugs or corners cut then that is due to laziness on the engineering staff who failed to build with quality under the tight deadline because quality is allegedly “free”.
Anyone who has actually read the book understands that the message of the book is to do the opposite. Extend the initial delivery estimate beyond the quality required to meet customer/market demand. Extend it to the level required to make the engineering staff proud of the quality of the product they have built and are excited to support it; not dreading supporting their newly minted “legacy code”. The time lost up-front for quality, will be regained (and then some) by increased long-term productivity and reduced maintenance cost. This is what makes the quality cost “free”.