Almost every time I’m talking about measuring how much time we spend on value-adding tasks, a.k.a. value, and non-value-adding stuff, a.k.a. waste, someone brings an example of refactoring. Should it be considered value, as while we refactor we basically improve code, or rather waste, as it’s just cleaning after mess we introduced in code in the first place and the activity itself doesn’t add new value to a customer.
It seems the question bothers others as well, as this thread comes back in Twitter discussions repeatedly. Some time ago it was launched by Al Shalloway with his quick classification of refactoring:
The three types of refactoring are: to simplify, to fix, and to extend design.
By the way, if you want to read a longer version, here’s the full post.
Obviously, such an invitation to discuss value and waste couldn’t have been ignored. Stephen Parry shared an opinion:
One is value, and two are waste. Maybe all three are waste? Not sure.
Not a very strong one, isn’t it? Actually, this is where I’d like to pick it up. Stephen’s conclusion defines the whole problem: “not sure.” For me deciding whether refactoring is or is not value-adding is very contextual. Let me give you a few examples:
- You build your code according to TDD and the old pattern: red, green, refactor. Basically refactoring is an inherent part of your code building effort. Can it be waste then?
- You change an old part of a bigger system and have little idea what is happening in code there, as it’s not state-of-the-art type of software. You start with refactoring the whole thing so you actually know what you’re doing while changing it. Does it add value to a client?
- You make a quick fix to code and, as you go, you refactor all parts you touch to improve them, maybe you even fix something along the way. At the same time you know you could have applied just a quick and dirty fix and the task would be done too. How to account such work?
- Your client orders refactoring of a part of a system you work on. Functionality isn’t supposed to be changed at all. It’s just the client suppose the system will be better after all, whatever it means exactly. They pay for it so it must have some value, doesn’t it?
As you see there are many layers which you may consider. One is when refactoring is done – whether it’s an integral part of development or not. Another is whether it improves anything that can be perceived by a client, e.g. fixing something. Then, we can ask does the client consider it valuable for themselves? And of course the same question can be asked to the guys maintaining software – lower cost of maintenance or fewer future bugs can also be considered valuable, even when the client isn’t really aware of it.
To make it even more interesting, there’s another advice how to account refactoring. David Anderson points us to Donald Reinertsen:
Donald Reinertsen would define valuable activity as discovery of new (useful) information.
From this perspective if I learn new, useful information during refactoring, e.g. how this darn code works, it adds value. The question is: for whom? I mean, I’ll definitely know more about this very system, but does the client gets anything of any value thanks to this?
If you are with me by this point you already know that there’s no clear answer which helps to decide whether refactoring should be considered value or waste. Does it mean that you shouldn’t try sorting this out in your team? Well, not exactly.
Something you definitely need if you want to measure value and waste in your team (because you do refactor, don’t you?) is a clear guidance for the team: which kind of refactoring is treated in which way. In other words, it doesn’t matter whether you think that all refactoring is waste, all is value or anything in between; you want the whole team to understand value and waste in the same way. Otherwise don’t even bother with measuring it as your data will be incoherent and useless.
This guidance is even more important because at the end of the day, as Tobias Mayer advises:
The person responsible for doing the actual work should decide
The problem is that sometimes the person responsible for doing the actual work can look at things quite differently than their colleague or the rest of the team. I know people who’d see a lot value in refactoring the whole system, a.k.a. rewriting from scratch, only because they allegedly know better how to write the whole thing.
The guidance that often helps me to decide is answering the question:
Could we get it right in the first place? If so then fixing it now is likely waste.
Actually, a better question might start with “should we…” although the way of thinking is similar. Yes, I know it is very subjective and prone to individual interpretations, yet surprisingly often it helps to sort our different edge cases.
An example: Oh, our system has performance problems. Is fixing it value or waste? Well, if we knew the expected workload and failed to deliver software handling it, we screwed this one up. We could have done better and we should have done better, thus fixing it will be waste. On the other hand the workload may exceed the initial plans or whatever we agreed with the client, so knowing what we knew back then performance was good. In this case improving it will be value.
By the way: using such an approach means accounting most of refactoring as waste, because most of the time we could have, and should have, done better. And this is aligned with my thinking about refactoring, value and waste.
Anyway, as the problem is pretty open-ended, feel invited to join the discussion.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
9 comments… add one
My view of refactoring is what happens in the section of “The Programmer’s Stone” on “The Quality Plateau” where they give a clear worked example. Starting with non-spaghetti code, they make it completely clear and concise.
I’ve rarely hit it on the first attempt (that works – passes all tests, etc.). Usually the process of writing causes one to think properly or to discover, but the first draft will NOT hit it since you don’t know quite what to do until you actually do it. It usually takes me 3 refactorings, the first affects less than 10%, but some subroutines are similar so should be merged, variables can be eliminated with states or context, fors and whiles ought to have been the other, etc. The second is usually only a few lines, and the third finds one or two things which can go either way, but I want it to be clearer or more efficient.
Can it be gotten right in the first place? Maybe, but I doubt there are a dozen living who can do so. There are thousands if not more who after writing it correctly can look back and say “Doh!”.
It is isn’t merely rewriting to understand something, it is reducing a complex set of code and data to a more straightforward one that does the same thing – provably, clearly, simply. Sometimes uncovering or removing bugs (sometimes as a side-effect). Sometimes it is easier to see what 20 lines of code ought to do and replace it with far fewer lines that you KNOW does what you assume the larger blob does.
None of that is a waste. At worst you’ve taken a blob you can’t verify and replace it with something verified.
I feel sad that this question seems like a tricky one for so many folks, but happy that I can cut the Gordian Knot and suggest what I believe is a simple answer.
Some years ago I coined the term “covalent” to indicate that any endeavour has many stakeholders, each of who must be at least minimally satisfied before we can all the endeavour a “success”. Tom Gilb has written extensively on this general topic too (how to agree on value from the perspective of many stakeholders, concurrently), as has Jerry Weinberg (“Quality is value to some person”).
As far as refactoring goes, I suggest we need to understand WHO (various parties) receives VALUE from the endeavour. Once this is understood, then the value of refactoring is obvious and manifest. IME It’s rare that customers see much, if any, value from refactoring efforts (and I don’t agree with Al’s classification btw, preferring to see “refactoring” in terms of Ward Cunningham’s explanation of Technical Debt http://c2.com/cgi/wiki?WardExplainsDebtMetaphor ).
– Bob
@tz – The example you share fits nice my understanding of value/waste classification. Actually my question isn’t “Is there anyone in the whole world who could have done it well in the first place” but rather “Could we have done it well in the first place.” The context is important and the last thing I’d like to do here is ignoring it.
So considering the whole story it’s most likely that you are right in the situation you describe. There are more stories though. Not everyone has comfort to start with a clean sheet and we very often work on legacy code which we haven’t written in the first place. That changes the context, doesn’t it?
@Bob – Although I like the bit about understanding who gets value (and what kind of value) out of refactoring I believe it doesn’t make this equation easier to solve. Conversely, it becomes even more difficult to assess.
Except of the most obvious cases refactoring won’t be easily assessed as value for every party involved in building software — exactly as you point. Then we come to a questions whether we can make every party at least “minimally satisfied” doing the work.
Finally, given that we were able to give positive answers so far, there is the question of how much it costs us. Or better, following John Seddon’s “manage value, not cost” how much potential value in other areas we won’t create while completing this very task of refactoring.
None of these is a question which is easy to answer. Well, most of the time at least. So while I like this perspective of considering how much value we get out of refactoring, I don’t really see it as a simple answer.
Well for me refactoring is about paying back the technical debt.
Technical debt has impact of the effectiveness of the teams – and their velocity. So if there is value in fast delivery, short time to market and stable pace than refactoring = value.
For me now, quality could be defined as possibility of delivering new feature fast and responding for changes at any time. And quality is value.
@Streser – Do you mean that fast delivery is always value? I can’t agree. Fast response to change always value? Again, can’t agree.
But even then, you can’t just consider this in isolation. Given that you work with legacy code but you barely change it – should you refactor the whole thing, because, well, it will make you responding to change better? Would that even be a sensible investment?
It other words, is it the biggest value your team can bring to your organization?
We’re just going through several months unable to deliver value because we have to pay back technical debt. If we had been able to refactor on the way, it may have cost more overall (or it may have cost less because the intervening code may have been easier to write), but the company would have still been receiving increments of value.
Yes, it’s a trade-off. But it’s one which comes with high interest payments…
@Paweł:
I’ve wrote ” IF there is value in fast delivery…”.
And I mean that for me “quality => possibility to fast responding to changes”… (but not only)
The question is how much could you loose (how much are you loosing) if you are not refactor code?
If your alternative beneffits are higher than your actual benefits than your actual benefits generates wastes…
I’m always saying that refactoring just for refactoring is waste and mistake… You shouldn’t do this! Instead of this you should refactor ALWAYS when you are changing something and adding value. Look at Scout Boy Rule from ” Clean Code” – @unclebobmartin.
Level of product quality which you need to set for your product depends on what is expected product lifecycle. For example if you are creating simple webshop only for one small customer you don’t need to care for product quality, cause when you will finish it there is low probability that you will be modifying it very often… From the other hand if you are creating universal BPM system which need to be customised for every customer(s) process, you need to take care for quality and refecator all the time to keep your code maintainable…
For legacy code, refactoring is to get it into a “known state”.
One partial digression: A common tool is sold by showing an example where a pointer to a password string might come in as null, and the vendor’s demo shows them adding an “If (pw == NULL) return;”. I went ballistic, but the others watching didn’t see anything wrong with that. My thought is if there is a flaw in a PASSWORD, you can compromise security. You don’t just cover-up or silence failures, or even compiler warnings. If something might fail, I want it to do so in an obvious, spectacular, diarty, flashing-neon-sign way. Not just quietly corrupt the integrity of the system.
I’ve had several cases recently where the choice was to take two weeks to untangle a complex time and interrupt driven state machine to change the interface, or just rewrite it without any of the complexity in two days. It was implementing an industry standard, so I could know what it was supposed to do without having to reverse engineer a spec.
But there are the in-between cases. You either refactor first at the local level making things simpler and removing redundancy (what you might hope a really good compiler might cancel out when generating code) then determine the macro behavior to find bugs, or try to understand and trace the tangled pile of spaghetti. Even if you don’t come near the quality plateau, at least it would be deobfuscated.