Home » Software Development » Afraid of reopened issues?

About Vlad Mihalcea

Vlad Mihalcea is a software architect passionate about software integration, high scalability and concurrency challenges.

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.

Reference: Afraid of reopened issues? from our JCG partner Vlad Mihalcea at the Vlad Mihalcea’s Blog blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*


Want to take your Java Skills to the next level?
Grab our programming books for FREE!
  • Save time by leveraging our field-tested solutions to common problems.
  • The books cover a wide range of topics, from JPA and JUnit, to JMeter and Android.
  • Each book comes as a standalone guide (with source code provided), so that you use it as reference.
Last Step ...

Where should we send the free eBooks?

Good Work!
To download the books, please verify your email address by following the instructions found on the email we just sent you.