Afraid of reopened issues?

Introduction

Reopened issues and developer feelings don’t mix well, a recurrent phenomenon I’ve seen on all projects I’ve worked on. Some might feel they’ve worked “in vain”, being reluctant to restart it all over again.

Reopened issues are bound to happen

There is a thin line between taking ownership of your current project and remaining professionally detached at all times. The only thing that matters is the value the customer gets for any given issue, even if it takes more steps than you previously anticipated. In software development the change is the only thing that never changes, that’s why you’ll always have to deal with reopened issues. Reopening an issue is not necessarily a bad thing, as you’ll soon find out.

What you can learn from reopened issues?

  1. The QA is doing it’s job

    There’s a good reason why we employ a “Testing” column on our Sprint boards. A task must obey the rules depicted by the “Definition of Done” policy, otherwise it might not deliver the promised business value. The sooner you test it, the least expensive the fix gets.

  2. The clients are not sure what they want

    Some clients have difficulties visualizing a flow until they are actually interacting with it. From a management point of view this is a waste of resources and it should be addressed accordingly. If it happens frequently then a “cheap mock-up” might be worth considering.

  3. A chance to challenge your design

    From a technical perspective the design is challenged to adapt with minimum effort. If you always have to rewrite everything to accommodate any unforeseen change, then you should definitely question your current architecture.

  4. A test for the peer review process

    If a task is reopened without a change of specification, it means the current technical solution is not properly functioning. The peer review process is aimed to prevent such situations, so you should check both the original problem and the review process.

  5. Recurrent reopened issues may indicate a brittle component design

    A bad design always surfaces in the form of reopened issues. If you happen to work twice as hard to accomplish a given task, you might reconsider your design or coding practices.

Conclusion

Reopening issues is just feed-back, and the sooner you receive it the better you can address it. Reopening issues is just a step in a task life-cycle. When you’ve finished developing a task, it doesn’t mean you’re done with it. This is the proper mindset for doing Agile software development. A task is done only when the customer accepts it’s business value. If you see the big picture you’ll be less frustrated by reworking a given functionality.

If you have enjoyed reading my article and you’re looking forward to getting instant email notifications of my latest posts, you just need to follow my blog.

About these ads

2 thoughts on “Afraid of reopened issues?

  1. Hi Vlad,

    My personal problem with re-opened issues is that they’re like Pandor’s box – once open, there’s no way to close it back.

    A re-opened issue will re-open another issue which will then re-open another issue – causing excessive delays to the project.

    They’re really scary, and they are often used for manipulative emails (for example, “Hey, I thought this was already done many months ago”, or “How come it’s not working again”)

    • TDD is a good solution to your problem, it greatly reduces recurrent re-openings for the same specs.

      If TDD is out of question, you can at least write the test to replicate the re-opening context, and then start fixing it.

      Regressions might happen, even with all tests in-place, as there might be corner cases or multi-module interactions which are not covered at all.

      I wrote this post from an Agile perspective, where tasks are reopened during a sprint or in the following one.

      The cascading re-openeing phenomena feels like a waterfall project that’s slipping on a bad slope.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s