Software Developers Don’t Need Permission or Forgiveness

This one is for software developers.

One of the basic ideas of agile software development is that the requesters of software have the primary responsibility to understand customer value and to explain “the What” to the people who build solutions; while the makers have the responsibility to determine “the How” when they build solutions.

Yet, a chronic problem throughout the industry is that the makers allow the requesters to dictate “the How.”

In particular, I’m thinking about the notion of keeping the software design clean at all times. In clarifying the widely-misunderstood idea of “technical debt,” Ward Cunningham reiterates that “the whole debt metaphor, let’s say, the ability to pay back debt, and make the debt metaphor work for your advantage depends upon your writing code that is clean enough to be able to refactor as you come to understand your problem.”

The term “technical debt” isn’t just an excuse to type code as fast as possible and ignore design. Nor is “refactoring” some optional, “extra” thing that we do if and when our business stakeholders approve of it.

Ron Jeffries has an article describing how fundamental refactoring is in the basic professional practice of a software developer. He explains how we can begin to clean up a code base incrementally, in the normal course of our work, without turning the exercise into a Hollywood production.

Software development techniques are not the responsibility of the project manager, customer, Product Owner, or any other non-technical stakeholder. They are the responsibility of the makers; the builders; the developers. Keeping the design clean at all times is a fundamental responsibility of professional software developers.

Don’t Ask for Permission

Don’t ask for permission to do the job you were hired to do.

The aforementioned Ron Jeffries tweeted some time ago that he wouldn’t ask permission to refactor any more than he would ask permission to write an “if” statement. (I haven’t gone back in time to dredge up the tweet. Trust me.)

You don’t “ask permission” to refactor. You do it naturally and routinely as part of your work. When you encounter a big blob of code that will require some time to refactor, you inform your stakeholders of the impact to the project; you don’t ask them, pretty please, if you might be allowed to refactor. It’s going to happen and it’s going to have an impact.

You’ve encountered a payback moment for so-called “technical debt” that someone created before you inherited the code base. The fact that person didn’t understand Ward’s intent with the debt metaphor doesn’t help you today. It doesn’t matter how red in the face the Product Owner gets about it; that particular User Story is going to take longer than it “should.”

There’s Debt and Then There’s Debt

If you want to play with the debt metaphor, then consider the situation to be analogous to owing money to a gangster. Your spouse or your business partner might insist you don’t have the money to give, because you’ll lose your home or your store if you pay it back right now. But if you don’t pay it back right now, you and your family/partner are dead. Literally. Saying “no” isn’t an option. Period. You’re on the hook for the money, even if the loan was taken out by a predecessor.

Just as the loan from the gangster wasn’t strictly legal, so the original technical debt in the code base wasn’t strictly in accordance with Ward’s definition of “technical debt.” Too bad. That doesn’t matter. The note is due now. Right now.

Don’t Ask for Forgiveness

Operate as a professional. Know what is right, within the scope of your professional responsibilities, and act accordingly. There is nothing to “forgive” and no one qualified to judge your technical decisions even if there were. You are responsible for “the How.” No one else.

If you choose not to keep the code base clean as you go along, then the cruft in the code will increase to the point that the system is no longer viable. It will happen before the planned production lifetime of the system has expired. And it will happen because of you, not because your stakeholders didn’t give you permission to refactor.

Do you expect them to have your back when the you-know-what hits the fan? “No worries; it’s my fault. I told them not to refactor, every single iteration for the past two years.”

They don’t understand the importance of refactoring because it lies outside their area of professional expertise. Therefore, the corruption of the code base can’t be their fault, no matter what they say. When the time comes for blame, they will say, “I trusted that team to know how to develop and support software, and they let us down.”

And they’ll be right.

“But We’re Not (fully) Agile!”

A common excuse to leave cruft in place is that the team or the organization hasn’t embraced “agile” fully, or not quite yet, or not at all.

I’m not talking about an “agile” thing here. It doesn’t matter if you’re working on a User Story from a Scrum Product Backlog or a task from a work package in a Work Breakdown Structure. It doesn’t matter if you’re working alone, in a pair, or in a mob. It doesn’t matter if you’re sitting in a team work space, an office, a cubicle, or a coffee shop.

It doesn’t matter if you’re doing greenfield development, enhancements, or a bug fix. It doesn’t matter if the code already has executable unit tests that make it safer for you to refactor, or if you’re using a full-featured IDE that makes it easier for you to apply refactorings to the code. Easy or hard isn’t the point. Agile or non-agile isn’t the point.

Ultimately it comes down to you and the code. And what you do is completely your choice. Choose wisely.

“But We’ll Be fired!”

This excuse has always puzzled me. Does a surgeon agree not to take the time to sterilize instruments because the hospital wants to process patients faster? Does an engineer agree to falsify inspection reports that show concrete voids in the walls of a containment building for a nuclear power plant because the prime contractor wants to avoid a penalty for missing a date? Does a certified public accountant agree to fudge numbers because her employer wants the books to look good for a prospective merger?

Could they be fired for “disobedience?” Sure. But they aren’t galley slaves. They have careers and reputations to think about. On balance, being fired from that kind of job isn’t scary. Professionals are likely to leave on their own initiative before it comes to that, once they’ve discovered what sort of organization it is. Are you a professional or aren’t you?

Are you worried about your ability to find work? According to Marketplace, the Federal Reserve considers a U-3 rate between 5.0 and 5.2 percent to represent full employment in the United States. According to Statista, as of June 1, 2018, the US unemployment rate for people in the “Information” sector is 3.5 percent. A good deal of that is due to people moving between jobs as they find better opportunities.

According to Workable, the average time to fill a technical job vacancy is 33 days. Incremental refactoring doesn’t increase the cycle time for User Stories by much. Having to pause to address a significant blob of technical debt will not introduce a 33 day delay in the release. A delay of that length would indicate the code is already nonviable. What, then, is the business case for firing you because you insist on doing your job properly?

Keeping the code base clean is part of the job. None of the usual excuses holds water. It’s 2018. It’s a little late for excuses, isn’t it? Just do it.