DevOps Zone is brought to you in partnership with:

I am a software architect passionate about software integration, high scalability and concurrency challenges. Vlad is a DZone MVB and is not an employee of DZone and has posted 60 posts at DZone. You can read more from them at their website. View Full User Profile

Afraid of Reopened Issues?

03.20.2014
| 2993 views |
  • submit to reddit

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 reviewprocess 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 tofollow my blog.

Published at DZone with permission of Vlad Mihalcea, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Lund Wolfe replied on Fri, 2014/03/21 - 3:52am

Sometimes requirements are not complete, or defects and context are not completely understood, or the application takes different paths for what should be the same type of data and stores it in different ways.  The implications of the change only become obvious later when it breaks some other data.

If this happens more than once in a great while, the application is probably brittle (#5) and is not (and can't be) completely understood.  Don't be afraid to rollback the fix and set the status to "won't fix" if it does more harm than good, regardless of how long the fix took or how well intentioned it was.  Not everything can be fixed.  It's not personal.

Vlad Mihalcea replied on Fri, 2014/03/21 - 4:26am in response to: Lund Wolfe

I haven't got to the point where I would admit that an issue couldn't be fixed at all. If the fix takes more than previously planned, it's time for brainstorming. There's always a way, even if it takes a whole module to refactor.

If this is the only solution for the fix and there is someone willing to pay for it, I see no reason why we'd drop the issue.

If the fix is to costly then your hands are tied. Everything has a cost, but sometimes it's not worth paying too much for getting too little.

Lund Wolfe replied on Mon, 2014/04/07 - 3:06am in response to: Vlad Mihalcea

I would agree almost 100% of the time.  Any application run should be independent or could be fixed to run correctly on the next instance of data.  Even when an issue is not completely understood, it should be possible to locate the specific code error and add a conditional to work correctly in that specific case.

Unfortunately, I have worked on one brittle application that saved project/document state that must be maintained as correct when that document is reopened despite it being "broken".  Sometimes this document/data can be retroactively fixed when opened and sometimes this can be hacked by adding version specific conditionals or new document conditionals, ugly as it may be, but not always.  Assuming that the application was modular, a module rewrite may fix the problem at the appropriate higher level.  A brittle application often implies a lack of modularity or intelligent design, though.

I'm not trying to weasel out of doing the hard fixes, but, as you say, sometimes the issue is or becomes a lower business priority than other issues or other applications, too.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.