It is better to deliver 20 projects with 10 bugs and miss 5 projects by two days than to deliver 10 projects that are all perfect and on time.
You never actually have such a choice, but if one did exist I'd pick 10 perfect on-time projects. The problem is I don't know what the 10 bugs are. While I'd like them to all be typos in the footer of the contacts page, they could also be data corruption or a password leak.
If I had ppl that delivered on time with no bugs, but at half the speed, it then becomes my job to do a good prioritizing the projects such that the half we do are the right half. I think the constraint of being half as fast might even force us to make better choices.
For any project, you're always balancing quality, schedule, budget, scope and risk to try to get the best business outcome. Because of this, I don't believe in any of the hard and fast rules about the "right" way to code. It's far too situational.
That said, you make an excellent point about the importance of project prioritization. A management team who is good at identifying high ROI projects will stomp all over one who sprays pointless change requests at their dev team.
(disclosure - I am the author of this article)
I think it is a matter of judgment. Bugs that bring the site down,I agree. Minor bugs that most people will not notice on a consumer site where we can quickly patch them, I would rather get more projects out. Where you land in between these positions depends on a lot of things.
Comments
Really good article.
One point I do disagree with is this:
It is better to deliver 20 projects with 10 bugs and miss 5 projects by two days than to deliver 10 projects that are all perfect and on time.
You never actually have such a choice, but if one did exist I'd pick 10 perfect on-time projects. The problem is I don't know what the 10 bugs are. While I'd like them to all be typos in the footer of the contacts page, they could also be data corruption or a password leak.
If I had ppl that delivered on time with no bugs, but at half the speed, it then becomes my job to do a good prioritizing the projects such that the half we do are the right half. I think the constraint of being half as fast might even force us to make better choices.
For any project, you're always balancing quality, schedule, budget, scope and risk to try to get the best business outcome. Because of this, I don't believe in any of the hard and fast rules about the "right" way to code. It's far too situational.
That said, you make an excellent point about the importance of project prioritization. A management team who is good at identifying high ROI projects will stomp all over one who sprays pointless change requests at their dev team.
(disclosure - I am the author of this article) I think it is a matter of judgment. Bugs that bring the site down,I agree. Minor bugs that most people will not notice on a consumer site where we can quickly patch them, I would rather get more projects out. Where you land in between these positions depends on a lot of things.