Archive for the 'Lean' Category

Technical Debt isn’t always Debt

After yesterday’s posts about why you should not focus on reducing technical debt and why that’s not an excuse to ignore it either. Dave brought up a good point in a comment.

Technical debt can be assessed like real debt, to a large degree. How much are you paying monthly because of the debt? An annoying little thing, or wanting to upgrade to a new version just for newness’ sake has a low interest rate.

– Dave Brondsema

But it got me thinking, perhaps “debt” isn’t the right metaphor for this at all. Annoying issues that don’t cost anything, and don’t technically need to be “repaid” aren’t properly debt at all.

Perhaps technical warts would be a better term for those kind of things. It feels good to fix them. But rather than feel righteous for spending time fixing them all and “paying down our debt,” perhaps we ought to feel a little bit self indulgent for spending time and money on what amounts to cosmetic surgery for our code.

I’m not saying cosmetic surgery is never valuable, or that warts are never painful, and certainly not that you should ignore them. After all warts can be cancerous, and could perhaps kill you. But after investigating and discovering that they are benign, perhaps it’s not worth the cost to have them removed.

Ignoring “technical debt” is like playing with dynamite

Earlier today, I posted the somewhat controversial Focusing on Technical Debt is a dead end and apparently I missed some of the subtlety required to get my actual point across.

I still don’t believe that it makes sense to focus on technical debt.

Technical debt is a fact of life, and it’s a sign that you’re writing better code now than you did before. It’s a sign that the team is learning, and that things are getting better. So, you should learn to live with it, or even to celebrate it.

But, that does not mean you should ignore technical debt either.

Technical debt can have real costs, can create real project risk, and most importantly can limit the capacity of the system to produce value. If it’s doing that, you need to fix it. But even then you are better to FOCUS on the long view of increasing the capacity of the system. In other words:

  • Make sure your whole team is learning from the process
  • Make sure you fix the things that impede progress rather than just things that bug you
  • Make sure that you do enough root cause analysis to know why the obstructions got there in the first place

In other words elevate the priority of learning above the need to “fix” things now. That way you’ll avoid future mistakes, get more done, and at the same time continue to deliver value to customers.

In the end I don’t like the term “Technical Debt” as a catch-all because it’s a way of lumping all kinds of different code problems together into one basket which results in trivium being treated with the same seriousness as potentially project destroying technical risks.

So, you do need to pay attention to all technical debt, but some of it should be ignored, some of it should be responded to immediately, and some of it should be “fixed” when you next work on code that touches that thing. Not fixing the critical things is dangerous, and I thought everybody knew that. My point in my last post was that fixing the non-critical things with the same urgency is more insidious danger.

Focusing on it exclusively leads to a weird situation where you’re fixated on the past, and not moving forward anymore. And ultimately it short-circuits the critical thing, which is growing the capacity of the team to deliver value.

People VS Process?

Lean Manufacturing people go around saying “it’s always a process problem.”

Meanwhile Gerry Weinberg, who wrote several books that I love, and gives lots of great advice, including the some of the best advice I’ve ever read about how to give advice, says “every problem is a people problem.”

So, which is it?

Are bad things that happen the result of bad processes, are they the result of things people do?

I’ve been party to a bit of discussion about this in the last month or two, and in the end it’s all pretty silly.

Processes are created by people, implemented by people, and are designed to accomplish the goals of people.

People run processes!

So, whenever something is broken, it’s people who will need to find the problem and fix it.

People can and do think of ways to improve processes everyday, but I’ll eat my shoe if you find a process that thinks of a way to improve people.

But there’s still a HUGE problem.

Modern companies seem to have a persistent failing — they look for people to blame when something goes wrong — and ignore the context in which those problems happened.

When something goes wrong, fire some people, and replace them with new people who make the same mistakes all over again.

Sometimes you “get lucky”.

The company might get lucky and find a person who’s able to raise awareness, reveal the larger contextual problems, and succeeded in spite of the fact that everything’s stacked against her.

More often than not though, the poor new guy doesn’t see the systematic pressures that caused everything to fall apart, at least not until it’s too late.

Sometimes replacing what’s broken isn’t enough.

Sometimes it’s the equivalent of a mechanic replacing your car’s engine several times in a row, because it keeps burning up — without ever checking to make sure oil is flowing normally, and the cooling system is working.

The easy way out.

It’s often easier to blame people because they don’t “control” them they way they do the context. This blame game is as old as the hills, but definitely not as pretty.

Help people fix processes

The solution is to ask people to look for the systematic pressures, give them the tools to find them, and to empower them to change the way work gets done.

In the end, people will improve the processes, if they believe they are allowed.

Sometimes a design isn’t working because you think you can’t change the one element that needs to be changed.

Ryan (via svn)

The same thing is true when you are designing the processes by which work gets done.

Urgency vs. Motivation

If stress is a weed, urgency is the seed.

Jason Fried

Just the other day a project manager I know asked me how she can “instill a sense of urgency” in her team. She wants to get more done, and get it done faster. Increasing developer productivity is a laudable goal. And she is being asked by internal and external customers for more and more stuff.

But I think there’s something wrong with the question. Urgency and “time pressure” are viewed as tools which can increase productivity. And I think this is wrong. But, it does work — in the short term.

In the long term motivation, tools, skills, and processes along with things like good unit test coverage, and good “architecture” determine productivity. Constant urgency, looming deadlines (particularly if they are artificial), and constant pressure actually hurt motivation, remove the slack required for building tools, discourage process improvements, and create all kinds of technical debt. This debt can be measured in terms of decreased test coverage, and “short-cut” coding techneques which undermine good architectural choices.

To put it more bluntly, urgency often produces short term results at the expense of long-term productivity.

If you push the question a little bit, as I did with my friend, you will usually find that the problem is not a lack of urgency, it’s a lack of motivation. Motivating people is hard, and if they have been burned out by too much “urgency” it just gets harder.

I’ve done it too. But now-days when I hear people pushing a “sense of urgency” I take it as an opportunity to start looking for deeper motivation issues.

Changing Values

It’s hard to change your corporate culture, because it requires changing the way people think, feel, and act. And smart people can do really stupid things when they try to change other people.

Once, long ago, I worked with a company that was struggling to attract top notch people in a very small field. The were constrained by the number of people they had, and the were loosing good people, who were hard to replace. So, they wisely decided that they needed to to change their corporate culture, and to make themselves a more attractive place to work.

Their primary tactic in achieving this strategy was to publish a new “company values” statement, and adding “cool” to the list of criteria by which employees were judged at review time. Figuring that if their employees became cooler, people would be more attracted to working with the company. At the same time they also hosted “mandatory fun” activities outside of work hours, on top of the mandatory overtime, and near-constant travel, which was the norm for many of their employees. Head In Sand

At the same time the manager, who was the force behind this, continued to speak condescendingly towards others he perceived as “less valuable” in the organization and was well know for his political games, and his “me first” attitude. This lead to widespread fear that the subjectivity of the “cool” rating was just an attempt to provide material for weeding out the “undesirable” employees.

Needless to say, their attempts did not earn them a worldwide reputation as “one of the most fun places to work.” And many people who felt their contributions weren’t valued left, and they told stories which made it even harder to find people in their small field.

If you want to change your corporate culture, you have to change the way people think, the way they feel, and the way they behave.

Changing people is hard. Rearranging words on paper is easy. Smart companies don’t confuse the two.

If you want to effect real change in an organization:

  • Start with changing yourself. You are part of the culture, and if you are a leader people are watching what you do more closely than what you say.
  • Be honest with yourself and with everybody involved about the problem. Take responsibility for your part what’s gone wrong.
  • Ask people to join you in the hard work of making things better.
  • Continually look for the reasons behind people’s resistance. Perhaps there’s a lack of trust, perhaps the your words are saying one things, and your actions are saying another.

Honesty, openness, and ability to communicate a vision of how things could be better will get you a long way. But you also need to be prepared for resistance, and you need to learn from that resistance. As Jerry Weinberg says:

“Overcoming” is not what you want to do with so-called resistance. What you’re calling “resistance” is what it looks like to you when [people] don’t feel safe following your suggestions. So, what you want to do is learn from it–it’s a gold mine of information, as long as you don’t push to “overcome” it.

Another thing you might want to consider in that most negative corporate cultures trickle down from the top. Contempt is the sulfuric acid of organizational change, it creates defensiveness, super-charges resistance, and corrodes working relationships.

So, if your managerial team shows any traces of contempt, you might want to do is buy a couple copies of Bob Sutton’s new book “The No Asshole Rule” and slip them on a few key people’s desks.