18

Allow me to add details: I work at an institutional place with many coders, testers, QA analysts, product owners, etc. and here is something that bugs me:

We have been able to sell crappy (albeit pretty functional) software for over a decade. It has many features and the product is competitive, but there are a some serious bugs out there, as well as thousands of "paper cuts" - little annoyances that clients need to get used to.

It pains me to look at some of the things because I firmly believe that if computers do not help to make our lives easier, then we should not use them. I have confidence in my colleagues - they are smart, able, and can improve things when the focus is on doing that.

But, it can be difficult to file bugs against some old functionality without seeing them closed or forgotten. "It worked like that for eons" is a typical answer. Also, when QA does regression, they tend to look for anything that is different as much as anything that does not seem right. So, a fix to an old problem can be written up as a bug, because "it has been like that before even my time".

The young coder in me thinks: rewrite this freaking thing! As someone who had the opportunity to be close to sales, clients, I want to give a benefit of a doubt to this approach.

I am interested in your opinion/experience as well. Please try to consider risk, cost-to-benefit, and other non-technical factors.

Job
  • 6,459
  • 3
  • 32
  • 54
  • 2
    I think you mean "...worked like that for eons." – Onion-Knight Jan 12 '11 at 19:17
  • Never rewrite. Unless its collapsing on itself (you cant add more withing breaking things) you would introduce more bugs then fixing when you decide to rewrite (as well as time) –  Jan 12 '11 at 23:57
  • If you're not losing customers now, some day you will. Someone will eventually convince folks that their software is easier than yours. Now, you probably shouldn't tackle this yourself. This is a culture change at your company... nothing you can or should do alone. – Brad Jan 13 '11 at 00:44

4 Answers4

14

I feel your pain.

But fixing something just because it is a bug is not a good enough reason.

You have to make sure your fix will not break any other code (not just yours but your clients code that uses your code). If you push out a fix and this breaks every customers system you will have some very disgruntled customers.

There are lots of famous examples where new code was written to replace an old system. Where they had to explicitly add the functionality of a bug in the old system because users depended on that bug (Not going to name names but I am sure you can google it).

Regression Tests are basically a test of what your customers expect to happen. Before removing a regression test make sure it will not hurt somebody (this is nearly imposable). If you can fix a bug AND this does not break the regression tests then it is a real fix.

Martin York
  • 11,150
  • 2
  • 42
  • 70
  • The regression testing part is true assuming that you actually know the appropriate level of test coverage. – Pemdas Jan 12 '11 at 17:39
  • on the other hand, if you code a GUI, then there are less dependencies; users evolve more easily. – Matthieu M. Jan 12 '11 at 17:59
  • @Matthieu M.: Absolutely. It is easier to change habits (as long as you invest in fixing habits) than it is to fix (lots) of automated systems (most of which people will have forgotten in the back room). – Martin York Jan 12 '11 at 18:01
3

some things to consider when deciding to fix a bug...in no way all inclusive.

  • Is it critical (the system crashes)? ...clearly these get fixed
  • Are customers often complaining about it? This could be a bug as in something is broken in the code or it could be a requirements bug such as the feature is not user friendly or they expect it to work differently.
  • From business stand point is it more beneficial to fix the bug or implement a new feature?
  • Does the bug require significantly architectural changes or is it in a part of the system that is heavily relied on by other subsystems? This could drastically impact testing time and complicate the necessary test coverage required to validate the bug? If it is really old it is sometime hard to understand exactly what else will be affect in the system by modifying the buggy section of code.
  • Are you losing potential customers because of a buggy system
Pemdas
  • 5,385
  • 3
  • 21
  • 41
  • On losing potential customers - that is hard for me, and even for sales/marketing to know, but the retention rate has been high (although the cost of switching is high as well). Arguably you can hardly know whether you are better of doing A as opposed to having done B, unless you are properly doing A/B testing. – Job Jan 12 '11 at 18:29
  • 1
    I am not sure how applicable this is in your case, but we often (Once a quarter) have a meeting with ourt sales engineers to discussion issues in the field that have prevented them from making a sale. This could include missing features, or something works badly from a user interaction perspective...ect. – Pemdas Jan 12 '11 at 18:33
3

Define bug. "The spec said sorted by date, but it's sorted by transaction amount" is not necessarily a bug in the code. It might be an undocumented change - sometime, somewhere, somebody asked to have the sort order changed but the spec, requirements, manual (even buttons and labels on the UI) weren't changed to match, and nobody minds. For you to show up and change it back to "by date" will cause chaos, and for you to update the ui, the spec, the manual etc is basically wasting your time, with the possible exception of a bit of "broken windows theory."

Some things are obviously bugs. If you click this button, it blows up. Or, if you click this button on Mondays, it blows up. Unless someone has tasked you with investing time understanding why, you could spend a lot of effort investigating. And once you find out why, it could well be that you can't change it, because that would ruin something that is more important to the users or to management.

If you see "sloppiness" - memory leaks, code that clearly needs some optimizing, indenting and naming conventions that don't match yours - it's super tempting to fix em up one day when you have nothing else to do, or on your own time. However, these "fixes" mess up the history in source control for little or no benefit, risk disasters like "we never compile that module because the binary we're using in production was built from code that's been lost, and you just overwrote it", and can seriously upset the people whose "mistakes" you're "fixing".

I recommend a one-on-one with your boss. Explain what is bothering you - is it coding style, things that you're sure must annoy users, inaccurate numbers, inconsistencies, or disaster waiting to happen? Then ask for direction and (this is key) take it.

Kate Gregory
  • 17,465
  • 2
  • 50
  • 84
2

If you want to fix a bug which has been old, you're going to have to be careful to not break any existing functionality. If there are unit tests, this is easier, but given the implied age of the company and software, they don't exist. I would recommend going through the book Refactoring by Martin Fowler because it goes over how to properly refactor and fix bugs while trying to minimize side effects. I would also recommend making sure the company is ok with you going through old bugs during regular time. They might only let you do this if you do it overtime off the clock.

Also, if a bug has become a feature i.e. it is actually used by the clients because it does provide something, make sure to provide a suitable replacement for when they want that behavior (or just document it as a feature instead of a bug).

indyK1ng
  • 815
  • 5
  • 11