Posts Tagged “programming”

“You keep using that word. I do not think it means what you think it means.”

-Inigo Montoya from The Princess Bride

It is not a good thing that use of the term refactoring has grown so common. I cringe every time I hear a business person say the word.

Refactoring is meant to be one skill of many that is second-nature to a journeyman programmer. While doing other work, the programmer chooses not to ignore rough patches or unnecessary complication within method-level bits of code. Instead, the programmer pauses to sweep up and simplify, leaving the code cleaner than when he started. Interfaces are not altered. Outward behavior does not change. The benefit is forward-looking – since cleaner, simpler code that does the same thing is easier to maintain and build upon. As a craft, refactoring is meant to go unnoticed (although not unappreciated) by the business and the end user.

A rewrite is just what it sounds like. When the system can’t scale to satisfy peak loads, or the user interface is clunky, or interfaces to external systems are bug-ridden and obtuse, we need to consider a rewrite of portions or all of the code. We need to get permission from the business. Sometimes, we need the user to buy into the investment of migrating from one system or UI paradigm to another. We need funding. Every time I hear a business person (or, so much worse, a developer) say we need to refactor some part of the system to fix an issue or inefficiency, another hair follicle leaps from the top of my head and embeds itself in the side of my ear.

Why do I care? It’s just semantics. Well … it’s only semantics until someone gets hurt. Rewriting code is a risky and sometimes painful endeavor. It doesn’t always end well. If we execute a rewrite but call it a refactor and the whole thing goes pear-shaped, no business person is going to stop and think about semantics. They’re just going to cringe the next time they hear the word refactor. And when a journeyman programmer comes along and someone lets it slip that the programmer has been refactoring code without telling anyone – it’s going to cause all sorts of unnecessary confusion and consternation.

The business will believe programmers are taking prioritization decisions into their own hands. They’ll think that risks are being taken by a team of “cowboys” who cannot follow disciplined programming practices. And they’ll be justified in thinking that, because we could not keep our terms straight.

Comments No Comments »

Once you realize that you’ve put yourself in a deep hole, please please please stop digging.

In the past few years I’ve been involved or drug into countless discussions about teams that have incurred technical debt. And I must admit to initiating more than a few of these discussion myself. The funny thing is that the theme of these discussion is almost always the same: “How do we get the business and upper management to understand that this system really will implode if we don’t start prioritizing some of this debt.”

I cannot, right now, recall a single time when the conversation’s theme was: “How do we stop digging?” I admit, that must have occurred … at least once … but I cannot recall it right now.

Yes, there are real business decisions that cause us to incur technical debt. Technical debt often results from a prioritization ethos that focuses on low-estimate patches and sidelines large or even mid-sized features. It can also result from a focus on revenue generation that entirely ignores cost savings. For example, imposing routine manual activities that may be better handled by simple ad-hoc reporting systems or crud maintenance screens.

This said, I’ve never seen a technical debt backlog that did not also include–or was even overweight with:

  1. Gaping holes in test coverage,
  2. Swaths of documentation-free code,
  3. Opaque data structures, and
  4. Duplicate methods and unnecessarily complex design.

All these issues (and more) result from team-level decisions, not business prioritization. Two months into a project these decisions cannot be undone without business consent. Moving forward, however, the team can stop making these decisions. Instead of decrying the existing technical debt, the team can first focus on disciplined processes that will reduce (if not stop) the team’s decent into further technical debt.

Clarifying and enforcing the team’s definition of done is the best way I know to quickly reduce the team’s creation of technical debt. Specifically, the team needs to come to an agreement about the documentation, testing, refactoring, and other activities that must be complete before a task, user story or feature can be declared done. The team and its individual members must also be mindful to account for these activities during estimation, thus ensuring that there is time to do things right the first time.

Simply put, the team needs to start to tackle technical debt by first enforcing internal discipline and best practices. Once these are established, the team may be surprised to find itself on much more favorable ground when it comes to tackling business-generated technical debt.

Comments 1 Comment »