The Engineering Managers Lament (Time/Quality/Cost paradox)

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.

"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

I found his analysis of the problem spot on, and I think a lot of companies would do well to generalize his advice to their own situation.

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.