Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

During the sprint review the product owner may say that a particular story is incomplete or the team itself may not have completed some committed tasks.

In what situations do you leave the code in the build? If the code is left in the build, is this a conscious decision made during the review? In other words, do you discuss this issue during the review?

Are there specific instances where code should be removed?

share|improve this question

5 Answers 5

up vote 6 down vote accepted

An incomplete feature should come out. But if this can be done without removing the code (feature flags, just removing the wiring, etc.) then that's fine -- preferable, in fact. Why? Because it limits the changes to a product which is already mostly-tested.

I would recommend that, if a story is medium-to-high risk, developers should always code with its possible removal in mind and make sure that task is as risk-free as possible.

share|improve this answer

The code for that feature never should have gone in to the release-ready codebase in the first place. This used to be pretty tough with server-based version control (e.g. SVN) if you weren't using feature branching. Nowadays with distributed version control (e.g. Mercurial, git) it's an easy thing to do.

In addition to tools, you may need to make process changes. For example, requiring that code be reviewed before it's merged, ensuring that the review with the product manager happens early enough in the iteration so that incomplete things can be course corrected and tested.

Bottom line is that you can't earn value on a partially completed story. Plus if it's not finished, the customer may change course with the next iteration in which case you have now caused bloat with a half finished feature.

share|improve this answer
    
How do you deal with Continuous Integration best practices if the code is not placed into the main branch daily? –  GuyR Sep 28 '11 at 21:14
    
Nothing says you can't have multiple continuous integration instances running. What I'm suggesting is a bit of a paradigm shift. You should be pulling changes into your local repository (integrating locally) often -- you just aren't pushing your changes to the release branch until they are ready. It's up to your team to define what "ready" means. Maybe it's smaller than a feature, maybe it's only complete features. The important thing is that with DVCS you have the flexibility to choose. –  Michael Sep 29 '11 at 15:07

Dead Code

Dead code, code that is not used, should always be removed unless it's going to be used in the near future.

Incomplete Stories

Just because a story is incomplete doesn't mean there is not value in running what you have. If there isn't any value in it then I think it qualifies as dead code.

share|improve this answer

If the code that is there already has sufficient test coverage (unit tests etc), then you can keep it as it will still be being tested. If you have not got much automated testing going on, then you should probably remove it as unused code will rot, and the state of it will only be known later when it is again used. Unused, untested code is mostly noise.

share|improve this answer

Do what makes sense.

If the code isn't going to cause any problems (say it's a function that can't be called), and/or if you are going to finish the story next sprint, then taking it out's just kinda wasting time pulling it out in order to put it back in.

If, on the other hand, the code is destabilizing something else, or is user-visible in a way that doesn't work, or it has the potential to break things, and you aren't getting back to the story right away, then removing it is probably the right thing to do.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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