Re: [scrumdevelopment] What is refactoring - was How much refactoring?
- I perceive (correctly or otherwise) refactoring as two things1. restructuring the code better once I have an idea what I needed, for reusability, maintainability, supportability, readability, etc.2. Resolving new concepts I didn't realize I would have to solve for (redesign) as I try to manage *unexpected* issues (like the fact that the vendor's software really doesn't do X, though the salesguy may have intimated very strongly that it does, or there's a bug in the OS we can't get the vendor to fix in time, or...).The problem we solve with refactoring is that we can't know up front what all the requirements really are going to be. New requirements will pop up, and we will, therefore, have some redesign to do. That, in my mind, is one of the key strengths of agile. Know your end goal (I wanna ride my motorcycle from San Diego to Las Vegas, not follow any paved roads, and be there in 4 days whole, hale, and healthy), pick your first destination (for today, I want to make it from my house to Barstow, CA), and get started. Along the way, unexpected obstacles will occur (a dirt road has been washed out and it's 15' vertically to the bottom. This wasn't here last year.) and I need to solve those problems to meet my objective (I can reroute, I can push my bike over the edge, hold it by the bars so it only falls about 9' and jump down myself, I can...).When someone dives in without forethought to the end system they're intending to deliver (e.g. 500 users was not a new requirement 3 months into the project), then they certainly do get a lot of work at the end. I'm definitely not recommending "full planning up front", but I had better know what the end product is supposed to do before I start down the path of coming up with solutions for the first step (sprint) or I might find myself further from my end goal than I had expected when I "get close to the end"Not quite right? Set me straight! <grin>Thanks!EricOn Thu, Apr 23, 2009 at 10:38 PM, Tobias Mayer <scrum@...> wrote:
What you describe is not refactoring, it is redesign due to the fact that you didn't do any sensible thinking ahead of time. Any design, of anything, requires the use of forethought. If you dive in without forethought then you basically get what you get -- in software this is usually a spaghetti mess.
I don't think that any Agile writer or practitioner recommends "no upfront design". The idea is always to do just enough. I still do not believe there is any value to measuring refactoring effort. If you are doing that you are likely missing something much more important, like how to effectively design systems.
> There's a team I worked with, after the fact, that kept their eye on each Scrum, but didn't keep an eye to the long term goal.
Measuring refactoring effort would not have removed or revealed this dysfunction. Talking with the PO may have done.
Eric Deslauriers wrote:
Tobias,I think you raised some good points, but to Luke's point, people need to have their eye on the end goal to minimize refactoring. There's a team I worked with, after the fact, that kept their eye on each Scrum, but didn't keep an eye to the long term goal. They refactored a LOT more than they needed to. And they also didn't meet their long term objective.I can't know everything (just ask my wife!), but I do know that the system I'm building will eventually have to support 500 concurrent users. If I build the app with that in mind from the get-go, I'll be much more effective & efficient. If I start building it like it was a single-user desktop app, I'm going to be doing some things I'm going to regret later (memory mgmt, threading, etc.).I know this because we built such a system in the 90s and one of the team members built his code in this way. It worked great for 1 user, but died at around 50. There was a fair amount of rework required to support the 500 users we knew we were solving for at the get-go. The rest of us had much less rework as we iterated through the project (what can I say, when I first heard of Scrum, I was like "Hey! That's kinda like what we do now, but even better!!")I would characterize the right amount as "Balance rework with ROI. Sometimes you just have to try it, and try it again. Other times, you should be able to get most of the way there the first time. Much of the work will fall in the middle since you'll learn things that change your direction."EricOn Thu, Apr 23, 2009 at 9:52 PM, Tobias Mayer <scrum@...> wrote:
I think this is the wrong question. You should simply refactor exactly as much as you need to, no more no less. Refactoring is not an additional activity, to be measured, it is an integral part of the design of an emergent software system.
> See the reason that I ask this is that Lean suggests that refactoring is wasted effort and that if you had designed the system correctly you wouldn't have to refactor afterwards. I don't really agree with this but I can see that there is an element of truth to this.
The only element of truth to this is the truth that you can know the entire system ahead of time, which is no truth at all, because you cannot. I suggest you ignore this thing that "Lean suggests". Lean (as if Lean were a person) knows a lot about manufacturing and very little about software design.
Refactoring, when done in accordance with TDD, is never waste. Waste would be designing the whole system upfront, or writing lots of "just in case" code, like pointless abstract classes that you think you might need in the future.
Your focus is on measuring "time spent" on certain activities, which you are attempting to tease apart. I am not sure why you are doing that. Perhaps a better question would be, how can we understand the concept of emergent design better? Just a thought.
I have been thinking on and off about this and after listening to a presentation on Lean and Agile I've thought about it more.
What % of an iteration is a reasonable % to aim at for refactoring? Is there a threshold that should be aimed at and if it reaches a certain % should you get worried. The answer is obviously yes as 100% refactoring suggests a poor design and 0% obviously suggests problems in the future or a damn good design.
I also know that there are going to be some that say "why are you measuring, there's no value ...". If that's the way you feel please start another thread.
See the reason that I ask this is that Lean suggests that refactoring is wasted effort and that if you had designed the system correctly you wouldn't have to refactor afterwards. I don't really agree with this but I can see that there is an element of truth to this. The tradeoff is really between how much you focus on designing for future stories and how much you refactor because you didn't design for the new stories that you knew where in the next few iterations.
So part of the question I'm posing is also about how much % of your time should you be looking at design and of designing for the future?
No doubt this is linked to where you are in the project too. Earlier in the project design/refactoring will take a higher % while as the project matures you would expect the design/refactor % to drop.
It's kind of like the tortoise and the hare. How much of a tortoise do I want to be and how much of a hare.
08 K1200S Tricolor (phreowww)
06 Husqvarna TE610
Sandy Eggo, CA (Ramona)
08 K1200S Tricolor (phreowww)
06 Husqvarna TE610
Sandy Eggo, CA (Ramona)