4

In my current company, in all software projects I've been in, there's usually a phase at the end of a project that eats some good amount of time and is dedicated to polishing new features so that they're ready for launch.

In Steve McConnell's book "Software project survival guide", he advocates doing that after each major milestone that's completed on a project (and possibly launching at that point too). Let's say that we don't want to launch after completing major milestones, because our product needs to be launched in a more coherent state. Have any of you had a positive experience with serious bug cleaning efforts done a couple of times during the project lifespan, as opposed to doing that before launch?

Improve this question
7
  • That's called Scrum. People do it all the time. You might want to Google "Scrum Method" and read some articles. After reading them, you might want to update your question to be more specific.
    – S.Lott
    May 13, 2011 at 21:33
  • @S.Lott I'm sorry, what? Scrum isn't about deliberate bug cleaning efforts. Agile in general and ongoing defect resolution/good coding practices, sure. But I feel you're being too picky here.
    – Adam Lear ♦
    May 13, 2011 at 21:39
  • @Anna Lear: The end of a scrum sprint often includes bug cleanup. Indeed, a Scrum sprint just to do bug cleanup is -- AFAIK -- pretty normal. I expect that a little time spent reading on Scrum would change the tone of the question from "Have any of you had a positive experience" which fringes on argumentative.
    – S.Lott
    May 13, 2011 at 21:57
  • @S.Lott I don't think it's argumentative as much as the poster's just looking for other successful approaches they could try.
    – Adam Lear ♦
    May 13, 2011 at 21:59
  • 2
    @S.Lott No, it means that I'm less interested in negative experiences, since I don't think that this approach is bad. I presume it's good. I am interested in knowing how well it worked. But being a non-native English speaker might mean that I am missing some subtlety.
    – Petko M
    May 13, 2011 at 22:07

6 Answers 6

Reset to default
3

At a previous company we spend a full day every two weeks fixing bugs. If we got the list finished we would leave early. It put pressure on everyone to find bugs that existed in the code. I prefer this strategy more than spending a week chasing bugs at the end of the project.

Improve this answer
3

We fix bugs when we find them and deem them to be of high enough priority. In practice we usually fix almost all bugs that are logged immediately. We never wait for the "end" of a project for bugs. We may push features to be after the initial release. Bugs are simply fixed when they are are considered the ticket with the most ROI.

Improve this answer
1

Isn't this one of Joel's checklist questions? "Do you fix bugs before implementing new features?" I think so. Anyway, after thinking about that question I actually tried it and, whaddya' know, it worked! Not only that, but finding the bug usually meant finding a couple more to boot. So now I'm sometimes pretty conscientious about it, putting off the new feature -- sooooo cool! so sexy! -- until earlier bugs are fixed. It works great.

Something else happened, too: the new hyper-cool feature I couldn't wait to add last week? Remember that sucker that I jumped out of bed (wait'll they see this shit!) to code? Well, this week it's just one more (yawn!) bullet item in the feature list. That was a brand-new insight for me: cool stuff becomes ho-hum real quick.

I believe this is a good thing.

Improve this answer
0

Don't do it. This is the development process equivalent of premature optimization.

When it comes down to the wire, and the final reviews start, it's not uncommon for features to be dropped. If you've wasted time debugging those features, that's time down the drain.

Conversely, features are also often added near the end of development. If you have to revisit a chunk of code in order to add more functionality, then you're reintroducing bugs into "clean" territory, which will leave you covering the same ground again during the debugging phase.

And finally, sometimes dependent libraries turn out to be too problematic, and get switched out or replaced. If you've developed workarounds to try to stem the flow of bugs, it's wasted time.

Knock it out in a working fashion, then go back and fix what's wrong with it in an orderly and systematic way.

Improve this answer
2
  • 2
    I can't conceive of doing this. If you don't fix bugs as you go along, how do you know that the new stuff you are adding isn't built on a foundation of quicksand? The more you layer on top of a system with known bugs, but deeper you'll have to dig to fix those bugs later. I guess it works for you, but it seems crazy to me.
    – Michael Kohne
    May 15, 2011 at 22:59
  • While I respect the alternate viewpoint, choosing not to release a debugged feature seems a pretty rare hypothetical compared to needing to release a non-debugged feature. In other words, the reason features get dropped at final reviews is because they haven't had enough debugging time.
    – Karl Bielefeldt
    May 16, 2011 at 1:43
0

Where I've worked there would be general bug clean up times done periodically as the combination of number and priority of bugs was high enough to warrant fixing the broken windows. Thus, this may be done a handful of times or more in a project that spans a couple of years for example.

Improve this answer
0

Ideally, bugs should be removed ASAP, (preferably before you put them in!). Some of the problems with leaving bugs hanging around are:

  1. It is difficult to estimate how long ckean-up will take.The nature of bugs is that you often know the symptom but not the cause.
  2. Bugs tend to hide other bugs.
  3. Bugs often prevent proper testing. Until the bugs are ironed out, you can't demonstrate that the application covers the spec let alone meets it.
  4. Developers will work around bugs and even treat them as features. This wil leave code messy and hard to debug.
  5. User's confidence in the application will be reduced if they see a pre-release version with lots of bugs in. Users trust themselves more than the app, so leading to spurious bug-reports and wasted time.
  6. Some logical bugs, when caught early, can be dealt with quite easily but when caught late will require substantial reengineering.
  7. Very few bugs are really low priority. If they are that unimportant, they probably exist in parts of the application that are also unimportant. In which case, there may be whole modules of code that should never have been written in the first place.
  8. Bugs are demoralizing to programers, leading to poorer quality and slower production of code.

Kramii's law of the day: There are times where developing new features is more important than bug-hunting, but these are less frequent than you think, even taking into account Kramii's law of the day.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.