I recently had a contract developer brought in to help out for a while. Pickings were slim at the time so when we found someone with good breadth of experience we made a choice. He certainly knew code, C#, ASP.Net and MVC, most of the complete Microsoft Development stack. He tended to ask questions, too many questions, LOTS of questions which often were not part of the scope of work I was trying give him. Questions are good, too many questions and lots of questions is another thing. When building something new, he was heads down, good and fast.

But when working on our existing web application and modifying existing pages, code, business logic he had this problem of not being able to just, debug, find the issue and fix it. He instead complained he didn’t understand the code, couldn’t read it, and would end up re-arranging the code, refactoring the code to the point it would no longer be recognizable by me when I needed to make a change in that area of the code. Don’t get me wrong, Refactoring code is generally a good thing, but when you have a deadline, or it’s a production fix there is no need to change that much code.

Did I mention that I work for a small IT department for a furniture company? When I say small, … I mean small (1 Network guy, 1 Help Desk guy, 1 Mainframe guy and 1 Software Dev guy… Me). There is no QA department, no QA team. The other IT staff steps in and tests changes when time permits, which is not often, usually 2 days before going live at a very busy time of year.

So, my contractor was used to BIG IT shops, with structure and a QA team. He was clearly used to quickly coding, making sure it compiled with minimal testing, and letting QA do the real testing. Well when you refactor as much as he refactored for small changes… you need a LOT of testing, and if your not testing, debugging, stepping through code, through all the changes and doing all the validations… it is NOT tested and the $%&*@ will hit the fan when it is in production at one of our 4 busiest times of the year and someone will spend countless hours, late into the evening and early morning hours fixing and testing so the next day in production is better or smother then the previous.

At the risk of boring you or losing you as a reader, let me detail one example for you.

The requirement:

• Product page view
• When the Qty of the item (SKU) in the cart is >= 1
  • Add Button to Update Cart
    • UPDATE qty in cart based on Qty in text box
    • IF the Qty in the text box is 0, then remove item from the cart

In the image below, you can see a comparison of prior code on the left and new code on the right.

• For some reason, he changed the existing method InCart to return the quantity of the SKU in the cart, existing method returned Boolean.
• Then sets isCartEmpty = TRUE if the inCartCount = 0, else FALSE.
          Variable isCartEmpty… BAD choice here, the cart is not empty, there are none of THAT SKU in the cart
• Then determines if you can ADD that SKU to the cart by checking !isCartEmpty
          In other words… that the isCartEmpty = FALSE
• Then determines if you can REMOVE that SKU from the cart by checking isCartEmpty

I’ll give you a moment to read that once more…
Yes, exactly, you can not add that SKU to the cart if it is already there, just change the quantity.
Yes, exactly, how can you remove that SKU from the cart if the cart is empty of those items?

Clearly, he did not test that small change, view the page and see if the buttons showed up correctly. He would have quickly noticed he could no longer add any items to the cart.

But it compiled, must work, check in the code change, move on……..