Terminology: Refactoring

Photo by Mark Nakamura

Photo by Mark Nakamura

Refactoring is a word that is often heard in software development organizations, and in some cases, it becomes a bad word.  How can that be?  It happens when the word is used but something else is happening—namely, rewriting or redesigning.

Refactoring does not just mean cleaning up code and making it easier to read and maintain.  If you have simplified the code but changed its behavior, you have not refactored it—even if you consciously removed behavior that is no longer needed or wanted.

Refactoring is “a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.”  From refactoring.com:

Its heart is a series of small behavior preserving transformations. Each transformation (called a “refactoring”) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

If you are redesigning or rewriting, please call it that.  In order for non-technical people to understand what refactoring is and why it is important, we must use the word correctly.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.

Terminology: Technical Debt

Photo by Anton Bielousovt

Photo by Anton Bielousovt

I realize that the idea of technical debt is already a metaphor, but I’ve found that it often comes with a stigma that bad decisions were made in the past, which is not always the case. And people sometimes don’t understand the severity of the technical debt that is accumulating in their systems. It's not just developers who should care about technical debt.

As another way of explaining technical debt, I’ve been thinking about the game Twister. In each turn of the game, the player has to make a decision about how to place his hands or feet on the colored dot that the spinner has indicated. Similarly, developers decide the architecture/design to use as they implement features. Early on in the game and in a new software project, these decisions are relatively simple. You tell the player to put his right-hand on red, and he can do this fairly easily.

But as the game continues, the decisions become more difficult. The player is contorted on the board, making his position more difficult to move from. His previous decisions were not necessarily bad, but it is challenging to make the next move.  Similarly in software, the architecture and designs used were not necessarily wrong, but they do not enable delivery of future features. For that reason, the player/developers must “refactor” the state they are in. 

And if the position that the player finds himself in does not get refactored to a more stable state, then he eventually falls down and loses. Game over. We do not want this for our software systems either—it is the point where we declare technical bankruptcy. Pay off technical debt early.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.

Terminology: Spike

Photo by iwona_kellie

Photo by iwona_kellie

Perhaps it shouldn't come as a surprise since I have a bachelor's degree in English, but I find it frustrating when certain words are used incorrectly.  Let's talk about spikes.  I've heard the word used to describe technical stories, development work that won't be tested (including programmers getting a head start on work for the next sprint), and work that is not sized using story points.

Taken from Extreme Programming:

A spike solution is a very simple program to explore potential solutions. Build the spike to only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story's estimate.

According to Ron Jeffries, "We use the word because we think of a spike has a quick, almost brute-force experiment aimed at learning just one thing. Think of driving a big nail through a board."  I also like the mountain climber analogy--you put a spike in the mountain on your way up; if the spike sticks, then it's ok to go that way.

If your team seems to include "spikes" in every sprint, investigate and see if they are true spikes or indicators of something else that needs to be addressed.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.