How to handle minor bugs that represent design flaws?

Question

I'm working on a project where I have a few related bugs that are fairly minor in terms of loss of functionality. They are basically minor but annoying aesthetic problems, and based on loss of functionality should be fixed eventually, but not as a top priority. However, these bugs are caused by a fundamental, baked-in design flaw that would be nightmarish to correct.

When faced with bugs that are functionally minor, but caused by baked-in design flaws, is it generally better to treat them as showstoppers to avoid painting yourself further into a corner, or treat them as low-priority bugs, continue with functionally more important stuff and hope that you'll figure out a way around them later, when the project is more mature and fixes for minor bugs are given priority?

Answer 1

I would continue as though it isn't a showstopper, but start mentally preparing for the fact that you may have to do a major rewrite eventually. If you don't end needing to do it, that's a bonus. Especially if you're working in a team or managed setting, ensure that it is clearly labeled as a risk in any future developments it could affect.

Answer 2

If the issues are minor in terms of functionality loss, and that functionality loss is not relevant in the context of the software solution being developed, I'd say you should try to check how limiting it can be to other future functionalities, and if it will not have implications within sight, go forth.

I say this because typically, when you finish a software project, no matter how small and nicely conceived, you will typically have a maturity at the end that will allow you to realize flaws and changes that you could have made in the design. Basically, if at the end you had to start it again, you would always do it differently.

Answer 3

Management always wants to see the return on their investment in your time. So, management wants to see a timely release and they also want to see that you fixed x number of bugs in y hours. But, that doesn't mean you need to ignore design. As you fix the bugs, prepare for a redesign of the part in which you see the flaws. After release, be prepared to present your reasoning of why it needs to be redesigned and how long it will take you to fix it. Write this down while it's fresh and while you're fixing these bugs.

In an ideal world, we would have an infinite amount of time to constantly re-work design based on changes in requirements. In the actual world, we have to weigh the cost of changing the design against the cost of continuing with the current design. You can start by quantifying the amount of time you've spent fixing bugs in the current design and comparing that to the time you estimate it would take to re-design this component.