I'm a software developer fresh out of grad school, been working in industry for 5 months now and I am very much still adjusting to the business world. Over the past 5 months I have learned a tremendous amount from my co-workers (amazingly supportive people btw), but one question that I can't get a straight answer on is:

Given a bug report or enhancement request, should I invest time into understanding the problem and fixing the root issue across the code-base, or simply addressing the stated issue with a high-level work-a-round and moving on to the next request?

Everybody on my team seems to agree that systematically addressing the root cause is better (for a multitude of reasons; including consistent bahaviour across the product, ease of maintenance in the future, etc), but given the near-constant in-flow of high priority issues, we seem to produce a startling amount of work-a-rounds ("we put out the fire out for now, we'll clean that up for the next major release...").

As far as I can tell, this attitude trickles down from my manager who is playing a balancing game between giving developers time and space to do things well, while also facing time and budget pressures from above.

Clearly, the only right answer can come from my manager, and maybe the VP of development, but I'm curious how other people deal with these two conflicting interests in product development?

(My question is open to all areas of R&D, not just software.)

closed as too broad by IDrinkandIKnowThings, Lawrence Aiello, DJClayworth, gnat, Mike Ounsworth Jul 14 '15 at 15:19

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    Hi Mike. This site isn't really for questions about "how to do your job" which this is. Rather it's for "personnel' type issues. We also have a "programmers" site which is a good fit for this kind of question. – DJClayworth Jul 14 '15 at 14:59
  • @DJClayworth at Programmers, matters of technical debt have been fairly thoroughly covered, eg in Does craftsmanship pay off? and multiple questions linked to it – gnat Jul 14 '15 at 15:11
  • 2
    @MikeOunsworth before reposting, consider investing some effort in checking prior similar questions over there – gnat Jul 14 '15 at 15:21
  • Most of this probably belongs into programmers.stackexchange. But the rule would be that you advise your manager if you are told to do something that you think is not in the best interest of the company, and let him decide. Just saying that the "near constant flow of high priority issues" might be a consequence of not fixing problems properly. – gnasher729 Jul 16 '15 at 17:54

You do the best you can with the resources available. If there is no issue queue then go back and clean. If there is an issue queue then put out fires. The logic here is that you don't leave pressing issues open when a band-aid solution is in place. The sign of a poor technical workplace is when your structure is all band-aids with no going back to clean.


Your question raises one of the longest standing debates in software vs business. Good developers want to do it right and from the root cause. Such is the nature of good developers who are passionate about their craft.

The reality is in business that's rarely to be the case; even in companies where software is the business. There are too many competing interests (management, deadlines, marketing etc.) to ever take a puritan/academic approach to writing code and fixing bugs all the time. The high level quick fix approach is rather commonplace both for the sake of business wanting here now on the spot type results as well as for reasons Keshlam pointed out.

In the end quick is almost always going to take precedence over doing it well (by true developer standards) because companies understand quick a lot more than they may understand right (until they have a profit eroding product fallout). Then they will want it right, but only for a time until they end up back in the same operational rut of complacency which got them there.

That is where it is your job to write quality code the right way if you can do it quickly and show the company the right way can truly be quicker and aligned with the business interests.


There is no single right answer. It depends on your customers, your delivery model, and how you're staffed. Remember, this is software engineering rather than computer science; trade-offs are expected.

Fixes to production code are often kept as minimal as possible to reduce the risk of introducing new bugs, even if that means leaving known exposures to be dealt with later. It isn't elegant, but it's what the business needs.

Also, a large customer may be losing a megabuck a minute while the system is down. Fast fix is essential, with cleaner fix deferred until time permits.

Quoting Steve Bois: "Make it work. Make it good. Make it great." In that order. If you can jump direct to great with minimal time and minimal risk so much the better, but we don't usually have that luxury unless we're developing de novo and with no schedule/resource pressure.


It depends. This is one of the questions that really depend on the individual attributes of each such ticket:

  • How much time will the quick solution take, and how much time will the proper solution take?
  • How much technical debt the quick solution will incur? Will it block you from doing other things?
  • If you do the quick solution, will you want to do a proper solution later?
  • Who is waiting for the solution, and why? Is it a client that need things done now? Are other developers blocked by it?
  • Who will be the one to do the quick solution, and who will need to do the proper solution? Sometimes anyone can do the quick solution, but the only developer that can do the proper solution is currently busy on a more important task.

You are correct that only management can come with the right answer, because they are the ones that see the big picture and can prioritize the different needs and implications of the different choices regarding all the tickets. But the developers are the ones familiar with the actual code and structure of the project, so it's your job to give to the manager estimates about the different solutions.


This is the trade-off we make in the business world. It's always a balancing act between priorities: Resources vs. Deadlines. Quality vs. Revenue. Scalability vs. Feature Set.

The manager and VP are the ones who know the variables best at any given moment, and should be clear on setting the priorities. No one can tell you what the balance is other than they. Google can put 10 people on improving their login page because it's used (any ideas, guys?) times per day. Your employee training portal in a 250-person company, maybe five times per day. O(n^2) to O(2n) may be worth thousands per month to Google. Your return on that would probably be around $0.15 per day.

This, incidentally, is why good architects are worth their weight in gold. Going in with a solid design initially will save you years of pain long-term.

Not the answer you're looking for? Browse other questions tagged or ask your own question.