Another solution I found to the Time/Quality/Cost paradox is to refuse it entirely.
Step out of the world-view that these are interchangeable at all. They are not. The mythical man-month has already shown that extra money won't make your software ship sooner if it's already late.
Time, quality and cost are related, but not directly. They are all functions of your team. A small team of expert hackers working in a smooth, tight process will deliver software quickly, of a high quality, and at a low cost. Take Github for example - 2-3 people who delivered world-class quality software in a few months, while holding down full-time jobs.
Conversely, a "bad" team or bad processes will deliver low quality that's inordinately expensive, and late - all quite consistently.
The solution, as always, is to get good people. Not many of them, and they don't have to be expensive, but they have to be good.
It sounds like you're just adding another dimension to the equation.. "team talent" might be appropriate. Of course it should be assumed team talent does not grow linearly with the sum of the team's individual talents.
"But code that is riddled with defects is a cameleon - one moment it works, the next it doesn't anymore. That leads to fear of refactoring, which leads to spaghetti code"
-
I couldn't agree more. We just had a new feature request come in last week, which I had to implement. 20% of my time has been devoted to writing the module and 80% of my time has been devoted to integrating it with legacy code. With each successive iteration it's taking longer to develop features then it did before, all because of the "pick two" agenda
According to the author, shipping code that erases your hard drive when you click "Quit" is not a defect (because it does so consistently), and fixing those kinds of bugs can be postponed. I didn't find his argument very convincing, though. The first time your customer clicks quit and has their drive erased, you will have an ex-customer.
This is a good point. There will always be bugs that need to be cherry picked for critical status. Managing criticals and blockers is also important in the development feedback cycle.
Step out of the world-view that these are interchangeable at all. They are not. The mythical man-month has already shown that extra money won't make your software ship sooner if it's already late.
Time, quality and cost are related, but not directly. They are all functions of your team. A small team of expert hackers working in a smooth, tight process will deliver software quickly, of a high quality, and at a low cost. Take Github for example - 2-3 people who delivered world-class quality software in a few months, while holding down full-time jobs.
Conversely, a "bad" team or bad processes will deliver low quality that's inordinately expensive, and late - all quite consistently.
The solution, as always, is to get good people. Not many of them, and they don't have to be expensive, but they have to be good.