Take the 2-minute tour ×

In an ideal world it is preferrable to meet the deadline with less bugs. But from your experience which is more preferrable/acceptable:

  1. Meet the deadline but has a number of bugs because developer rush into things
  2. Less bugs but not quite meet the deadline because the developer is very rigorous in writing the code
share|improve this question
What about dropping features? In my experience you are able to do an acceptable release on time if you are able to drop additional features if they don't fit into the project anymore. You should book enough time to get rid of bugs at the end of the project. Anything that hasn't been implemented until then will have to wait until the next release. –  Anne Schuessler Jan 18 '11 at 7:21
Get out a relatively bug-free release first. –  abel Jan 18 '11 at 19:46
When you are doing true scrum, bugs exist for no more than a week :) Benefits: A) paying for bugs upfront is way cheaper, and B) When you pay upfront, you know what the true cost is. –  Job Jan 18 '11 at 22:45
XKCD is as relevant as ever. xkcd.com/844 –  Maxpm Jan 19 '11 at 5:22

12 Answers 12

up vote 4 down vote accepted

The answer to this question depends heavily on the business goals, as well as the client.


If you are doing business with an enterprise level client who is well established in the marketplace, they are less flexible and cannot adapt to changes as quickly. Therefore, stability is an absolute requirement in most cases. There are exceptions for research and development and entering new verticals. Faster finishes first in some cases.

These types of clients generally understand that good software takes time to develop, and will work with you to try and meet the goals.


For a new startup, the rules are drastically different. As a startup, you need to know right away if the product that you are building will indeed fulfill a need as your marketing research predicted. For a startup, getting a prototype out in the market as fast as possible can garner lots of valuable feedback about the direction the product should go.

It can also establish you as the market leader, helping you gain valuable market share in a new vertical before it becomes saturated with competition.

Since startups are small, flexible, and can rapidly adapt to change, this model works out best for them.

In summary, there are other factors to consider, but the main idea is that every project is different and will have different quality and time to market goals. It's up to executive leadership to determine an effective business strategy that includes thorough analysis of the opportunity costs of choosing one method over another.

share|improve this answer

or... 3. Cut non-essential functionality

Sometimes, because of the technical candy or the candy features requested by the client, deadlines are hard to meet and inherently a bigger ammout of bugs arise. It is the KISS and YAGNI principles applied.

Quoting from this book, "Rework", the essential/core/epicenter from your software is what the business needs to function, just as a hot dog stand can be a hot dog stand without any toppings, what you can't cut out are the hot dogs.


One of the hardest things to learn is how to keep clients happy, and in my experience, this can be more easily accomplished with smaller product iterations.

Sometimes deadlines demand the software working at a heavy production level since day one. Managers/clients don't always know (which is most of the time) what they actually need for the software. So try to cut non-essential functionality and keep quality. In the end it depends on how critical the production environment will be, but try to cut out extra features and deliver quality. Quoting again from "Rework":

Doing later also means doing better

...and also meeting deadlines with less bugs

share|improve this answer
This is orthogonal to the original question. Many times, you simply can't cut functionality. It's good when you can, but I don't think this by itself is a good, generic answer to the question. –  Jason Baker Jan 18 '11 at 6:06
functionality is essential. all of it. –  mauris Jan 18 '11 at 6:12
Not all functionality is essential. –  Jürgen A. Erhard Jan 18 '11 at 6:51
Not all functionality is essential. A lot of it can be nice to have or can wait until the next release (assuming that there is a next release planned). I've never worked in a project where there wasn't some features that could be cut. –  Anne Schuessler Jan 18 '11 at 7:25
Usually if you ask the question that way "Is all of this functionality essential?", the answer you get will be "Yes!". However, if you break it down into small enough chunks, there are usually aspects to the functionality that the developer thought was essential, but that the client doesn't care anything about. This takes constant communication to discover. Also, if you ask the client to rank the functionality, there are usually a couple items at the bottom of the list that can fall off, or wait until after the "deadline". I don't find this answer to be orthogonal at all, it seems dead on. –  Marcie Jan 18 '11 at 20:33

Meet the deadline, and present a list of Known issues.

People HATE finding bugs, but if they have been told up front, they tend to be much more lenient.

share|improve this answer

Well, you can frame it this way: do you want to pay for quality now or later? Either take the time to do it well in the first place, or spend time later fixing all of the problems. I would argue that this post-feature-development bug fixing phase may be more expensive because it can also be riskier and more prone to hacky solutions since the existing code is already in place and probably not high enough quality.

share|improve this answer
That's a very good point. :-) –  jpartogi Jan 18 '11 at 6:01

This depends entirely on the situation....

There are many factors to consider:

  1. How easy is it to roll out patches?
  2. Is it possible to release a basic, stripped-down version and then patch new (edge case) functionality in over time?
  3. What is the general culture of the client industry for such a product? Do they expect one-off perfect releases, or are they used to the idea of an evolving system which may be buggy when first released?
  4. How much risk to the business does a buggy initial version pose, as opposed to blowing the deadline?

In short, there is no black and white answer to this. For example: For something like an embedded system which is difficult and expensive to roll out to devices in the field, it may be best to try to wait (renegotiate deadlines if possible) and get it out as bug-free as possible. On the other hand, for something like a large web portal system (written as a web app) which can easily be upgraded at any time by rolling out fixes as they come out, it may make more sense to release an initially dodgy version, and then patch issues (and edge case funcionality) as you get to it.

But at the end of the day, in my experience this has been more of a business decision than a technological decision. If you're in a situation where missing the deadline is a super big deal, while having a buggy initial version is not (or vice versa) - you'll want to weigh these things up when making the decision.

NOTE: As a programmer, of course I prefer the idea of polishing up a product as much as possible before unleashing it (heck, I'd rather have no deadlines at all, ever ;)). But realistically, this isn't possible in real life. Often, a stripped-down initial release is a good middle ground solution.

share|improve this answer

I think it depends on the bug. Do you want to delay a release to fix a bug where the app crashes the minute it's launched on any computer? Yes, definitely. Do you need to fix a bug that happens only on Windows ME while there's a full moon out? That can probably wait.

If it's a critical bug, it's preferable to do number 2 hands down. The reason being that it costs exponentially more to fix if you have to push that fix out in an update.

For less critical updates, you can release a bundled update which reduces that cost to some degree.

When in doubt, I say you go with #2, but I wouldn't be surprised to get pushback from management with that approach. I suspect that managers tend to be judged more by how good they are at meeting deadlines than they are at not causing needless critical updates.

share|improve this answer

Well as far as testing is concerned it is never finish. it is over but never finished.

Go for the launch with bugs with severity and more priority taken care off.

share|improve this answer
Yeah, but you don't commit suicide because you're going to die anyway. You lead as long and healthy a life as you can. By that same token, you don't just push crap out just because it's never going to be finished anyway. You try to make it as finished as you possibly can. –  Jason Baker Jan 18 '11 at 6:03
Well said @Jason. +1 –  Dan McGrath Jan 18 '11 at 6:34

Meeting the deadline with lot of bugs makes you poor in the industry, and the customer won't come to you again. You can talk with the customer to get the delay by two or three days.

share|improve this answer

If you look at this from a final user, i would be quite pieced off if someone promissied to do something for monday and when i tried to use it it does not work, or it's all buggy.

But if you look at the "procedural" side, it means that the application needs more testing and its part of the natural life of software.

My best approach is to try to make things work the way they should work (if its a major module, dont pay attention to details, login in form should login but anyone will get piced off if you dont show a notifications afterwards).

share|improve this answer

Neither. Why not bake quality in with your code? Be able to meet deadlines with quality code? You may push out less features, but if quality is baked into the process you can achieve both.

What happens now is you'll need an empowered team lead or dev manager who can give the business push back and have the conversation around 2 things:

  1. Quality baked into code = 2 less features per build
  2. Prioritizing highest needed features from the stakeholder as to what they REALLY need.

Then you can focus on the highest value features and push them out with excellence.

share|improve this answer

This is a question only you can answer. It depends on the type of product, who the customer is, what the customer is demanding, etc. There's no way for us to give a simple 'a or b' answer. Its completely situation dependent.

But I will remind you that the cost of fixing a bug after release is far higher than fixing it before release. So factor that in when deciding whether or not to wait until post release to fix a bug, as you will be expending more time/effort/money on it.

share|improve this answer

I have seen a lot of PMs afraid to tell the client that we can't meet the schedule and insist we ship with known bugs. I can tell you that every time they do tell the client, he is usually far more interested in less bugs and a moved deadline. I guarantee they will remember the bugs more than the missed deadline unless the deadline is absolutely unmoveable (such as the start of the tax filing season when you are doing tax software) or will affect some other things which will be very costly to move (IMHO 98% of all deadlines do not meet these criteria).

share|improve this answer

Your Answer


