Seize the deal!
You missed out!
Imagine having a tool that can automatically detect if you are using JPA and Hibernate properly. Hypersistence Optimizer is that tool!
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.
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.
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.
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.
From a technical perspective, the design is challenged to adapt with a minimum effort. If you always have to rewrite everything to accommodate any unforeseen change, then you should definitely question your current architecture.
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.
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.
Reopening issues is just feedback, 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.