
The Engineering Managers Lament (Time/Quality/Cost paradox) - TimothyFitz
http://startuplessonslearned.blogspot.com/2008/10/engineering-managers-lament.html
======
swombat
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.

~~~
acgourley
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.

~~~
swombat
Definitely not. In fact, I would say that it shrinks exponentially with the
number of people on the team.

The best way to turn a genius into an average person is to force him to work
in a committee with 20 other geniuses.

------
habs
"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

------
acgourley
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.

------
adamc
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.

~~~
acgourley
He chose that example poorly and you're taking it too literally.

