“Fast, Cheap, Good – pick two!”
In any software project (or probably any project where you are creating something), you cannot lock down all three of these dimensions–i.e., you cannot define what you want for all of them. If you are very experienced, realistic, and have control of all external factors, you might get close. For most projects to succeed, one of these dimensions needs to be more relaxed than the others.
Fast and Good
The usual expectation is that “fast and good” won’t be cheap. Lots of people or money will be needed. But lots of people does not mean it will be done fast (see the book “The Mythical Man-Month”). So part of the solution is usually bought instead of created. That gets it done fast. But will it really be good? Maybe if you spend a lot of money, to buy something really good–essentially, you’re paying for the time that others spent on it at another company. This also assumes the part you buy will be exactly what you want.
Good and Cheap
The expectation is that a “good and cheap” solution will take a long time–that one person working on a project for a long time will be cheaper than lots of people. But will it really be good? Usually, it takes more than one person to make things good. For example reviews, proofreading, and brainstorming requires at least two people. So a few people over a long time could make a good product, but that doesn’t sound like it will be all that cheap (unless the people work for free).
Fast and Cheap
“Fast and cheap” is not likely to be good. And that is the usual way projects are started. The project gets accepted by most companies when those paying for it are convinced that it can be done fast and cheap. The assumption is that it will need to be just good enough for customers to want to buy it.
Cost, Features, Quality
But let’s break the discussion across slightly different dimensions, because “fast-cheap-good” may be a fun quip, but most product and project discussions revolve around Cost, Features, and Quality.
Cost includes the “Fast” and “Cheap”,dimensions: time, materials, resources, people, etc. needed to create or support the software.
Features includes part of “Good”: It’s mainly about the content and how the software works
Quality includes the other part of “Good.” Quality is related to how well things are implemented–for example, is the software stable, is it intuitive, do users like it?
Guess which of these dimensions is always last.
Cost? Nope. Got to make it fast and cheap. People: Got to use the least number because people are an expense. And keep the team working hard–no slacking off. Time: Got to get it out fast, to beat the competition. Money: Got to use the least $, because why would anyone waste money?
Features? Nope. Getting in the maximum number of cool features is what will beat the competition.
Quality? Yep. The product only has to be “good enough” to include the maximum number of features, with the minimum use of resources.
Lots of companies say “Quality is number one.” Is it really? Here’s a quick test to determine a company’s priority on quality: Just look at how schedules are defined. Is quality at the end of the schedule? And is the major emphasis on getting things done fast, fast, fast, and on “DO NOT SLIP the due date!”? If dates and other resources can’t be changed, Features or Quality are all you can cut. If quality was number one, then engineers would write code that would be easy to test–does the Quality Assurance department get to send the code back because it’s hard to test? (That’s how it WILL be if they were not included early in the project.)
Who decides if there is “enough” quality? Managers, a quality team, the creators? It is a mistake for any one of these to have the ultimate authority. Most people would say the Managers should have the final say. The Challenger Shuttle accident was fundamentally caused by the managers overriding the engineer’s concerns–“make the schedule” trumped launching within known temperature ranges.
What is missed by not including quality? Creative types are motivated and satisfied by creating good work. Customers enjoy using good quality products and will pay more for them if the quality stays high. But in an economy where “cheaper” is always favored, quality will be the primary way of making things cheaper, with features being a close second.
So what about planned obsolescence?
It is well known that there is planned obsolescence for physical products–to “overdesign” a product so that it will last means that once everyone who wants it has it, sales could dry up. So products are designed with less than optimal materials (lower quality) so that they do not last. Or they last only until a better product is offered.
What is the software equivalent of planned obsolescence? Defective and poorly designed applications are shipped, so that new and improved versions can be sold. Software’s planned obsolescence is assured by not investing “too much” in quality, and the best way to limit quality is to have short aggressive schedules with too many features. First to be cut, when there is not enough time, is quality; only then are features cut. If enough features cannot be cut (because the product won’t be competitive), only then is the time allowed to expand, but only just enough to meet a minimum quality level. It is unusual for a commercial product’s schedule to be increased to assure a high-quality level, with no feature cuts. Of course, schedules are increased to improve quality when it is obvious the quality is extremely low. But it will only be increased just enough to get “adequate” quality.
So now you know how obsolescence is put into software. It isn’t directly planned, but the result is defective software from a user’s perspective and eventually horrible legacy software from an engineer’s perspective.