Despite what your boss might like to think, Bugs are a fact of Software. There’s a number of things you can do to minimise the occurrence, the severity and the impact bugs might have, mostly centring around having a reliable set of Unit Tests. Regardless of your best efforts, they will still find a way through the net, it’s how you handle them that matters.
My first piece of advice would be to be honest about them, and the root cause, however embarrassing to you or your team it might be. It’ll be too late to cover it up, so don’t waste your time thinking of excuses. Get to the root cause and come up with a plan to resolve it. If it’s a major problem in Production it’ll be on your shoulders to come up with a strategy to expedite a resolution. Continue reading “Development Team Leadership First Steps : Part 12”
I recently read The Software Craftsman, as mentioned in the review, one of the areas that struck a chord with me was the viewpoint on Legacy Code. I deal with a lot of Legacy Code in my day job, I’ll share a few of my own thoughts and experiences on the matter.
Legacy Code – Respect
It’s important to treat Legacy Code with Respect, from all angles. Treat it with respect regardless of how poorly some of the code may have been written, or how antiquated the technology may now be.
The term Software Craftsmanship seems to be rather divisive in its support, with, as mentioned in the book numerous times (along with retorts) the fact that the movement can come across as elitist. At it’s core it’s another manifesto, a fairly open-ended one at that, but having read the book it extends far beyond this.
In much the same way as Agile, in the pure sense, is more of a mindset than a prescriptive set of rules, the ideas behind Software Craftsmanship conveyed in the book really lean towards achieving excellence, building on and complementing a lot of the practices outlined under XP and Agile.