Software Craftsmanship

Thoughts on Refactoring

Thoughts on Refactoring

I recently worked with a team on a fairly significant refactoring. I paired with different team members each day over a three day period as we moved code around, pushing responsibility into other classes, reducing complexity, and make the code more expressive. On the fourth day, I put together some notes on the things we saw and general guidelines for the team to keep in mind. Nothing herein is new to the community, but it might be new to you.

Technical Debt and Accountability

Technical Debt and Accountability

I am wrapping up my second in a series for Clean Coders on Technical Debt. In the first episode, I explain the Technical Debt metaphor, how it originated, how it changed over time, and how it now is commonly understood in a way that is the opposite of what it originally meant. I talk a bit about the limitations of metaphors and how debt in particular has not served us well as a metaphor over time. So when a link to an article on the "Limits of the Technical Debt Analogy" hit my inbox this morning, I was quick to follow the link and see what the author had to say. 

Unfortunately, this article is not at all about the limitations of the metaphor. The article is about how people other than those who write the software are responsible for the quality of the software. This article is bunk.

Code Profiling

Code Profiling

I recently gave a talk on the role of a Quality Analyst as an organization transitions from waterfall to agile. The talk was entitled "Switching Horses in Midstream" and covered a number of topics. One item in particular struck me as worthy of blogging about. It's a technique I've been using for years, but have never written about it. So here we go:

Legacy code bases with a lack of test coverage are often trepidatious places to hang out. You never know when a simple abstract method is going to create a sink-hole of logic and reason, eventually leading to your exhausted resolve to revert and leave it dirty.

Good Software

I saw a tweet this morning that caught me off-guard.

If your software makes money it is good software by definition. Nothing else matters. #Agile ^ @SkankworksAgile — AgileFortune (@AgileFortune) July 23, 2015

It doesn't strike me as consistent with the type of thing AgileFortune usually tweets. My initial reaction was to reply via twitter, but didn't feel I could express my thoughts well in 140 characters or less.

Unit Testing is to code coverage as Exercise is to weight loss

This is a quick post, following up on a tweet from a little while back:

"Unit testing is for code coverage like exercise is for weight loss. You're actually missing the point."

A great number of people in the software field appear to think the primary benefit of unit tests is test coverage. Some even talk about them as if they were one and the same. "No need for more unit tests, we have plenty of coverage already."

Estimating our Work

I've been thinking quite a bit about estimations and our general obsession with getting them "right". After all, we need to know when the project will be done. And we need accuracy. Knowing the entire project will be done before the end of the third quarter isn't good enough. We need to know that the project will be done this month or this week or perhaps even on this specific day.

"Necessary" Refactoring

In a discussion on the Agile Alliance Linked In Group, Michael Moles asked how refactoring fit into the agile process.

The Question

Refactoring: How does it fit into your Agile process?

We are in the midst of writing a new product, at this point the developers are realizing that some of the code should be refactored to improve performance and or clarity for ease of use. How do you fit refactoring into you Agile process? We have created separate backlog items for refactoring specific pieces of code. These backlog items are treated exactly like any other backlog item (meaning they have effort assigned and are committed to sprints by the team). What do you do when refactoring is necessary?