Quality software is Code that delivers the intended andconsequential business value while also keeping a minimal amount of maintenancecost after it’s delivered.

Here is my recipe for successfully delivering this. Take it or leave it... seriously it's just how I personally do things and i'm definitely willing to hear some feedback just don't expect me to argue that there is one best way. This is just 'my' way... one of many possible ways.

Acceptance Test Driven Development or Behavior DrivenDevelopment is the first step.

Let’s take what everyone is familiar working on… a defect.Generally a customer experiences some sort of behavior and it is undesirable.They call in, they are pissed, they want you to make it work correctly forthem.

Reproduce the issue. This is first and foremost… you can’tfix something you can’t see. Reproduce the issue and while you’re reproducingthe issue gather as much information as you can about what the root cause mightbe.

Figuring out the root cause is something that I often have ahard time explaining to people. I generally think of finding root cause as similarto troubleshooting. First if you have a problem… divide the problem in half andsee where it follows. In the case of software… if you have multiple classes orcomponents in play try to isolate them with known working components or in aunit test harness/fixture.

Reproducing the issue in a unit test with a debugger is asure-fire way to see what is going on that is wrong.

Note: if you cannot figure out how to reproduce the issueand it’s only reproducing in a customer’s system then your first step should beto Create More Robust Logging around the problematic area. Debug loggingin  a production environment is essentialno matter how well you use TDD or ATDD and no matter how great your programmingability is. Just be careful not to break any privacy or data storage laws(things like credit card CCV2 for example are illegal to store)

Once you can isolate the issue to a certain area of codethen you absolutely MUST identify what components need to change to fix theissue. (DO NOT FIX YET).

This is like a level of effort examination. Inform yourtester what all you plan on changing. You know the person who has to determinewhat will need regression tested after you go fumbling around in the code.

Programmer:Ahh yes package A, package G, class C, Class F,method G, method Z…

Tester: oh really you have to change package G? I guess I willhave to regression test Foobar then.

Create all the appropriate project level reporting stuff atthis point (tasks with estimates for example, in scrum)

Now write unit tests for every class/method that you will beimpacting with this change. Use “Right BICEP” to test and refactor as needed toadd tests (See Working with Legacy Code)

The whole time I’m doing new unit tests and refactoring, I amconstantly going back and checking things out in the UI to make sure that Ididn’t break anything. Follow as many paths through the code as you can (preferably100% of them). Some gui based automation could help here too.

OK NOW fix the code using TDD.

Re-run all the automated unit tests (including your new testthat checks the bug)

Get a code review

Refactor as needed

Re-run automated unit tests

Do user acceptance testing.

Release to customer.