Re: [scrumdevelopment] Refactoring Justification Language
The case for refactoring doesn't depend entirely on the inevitability of changing requirements. Even with static requirements, my first coding/design attempts will be suboptimal. I could stare into space and try to come up with the perfect code in my head, then type in perfectly at the keypunch machine. But I'll learn more by trying some design, then partially melting it down and reconstituting it after some reflection.
It's an academic point, since a static understanding of the requirements doesn't exist, but might be useful when a client doesn't realize that yet.
Looking at the question behind the original question, probably a lot of other stuff could stand improvement if the team doesn't see the point of refactoring. The times I've been sent out to address specific "engineering problems" I've discovered pretty severe management or teamwork issues.
--mj
On Jun 30, 2010, at 3:54 PM, Adam Sroka wrote:
That's a great article. The main thing it adds, that neither Michael nor I said, is that changing requirements are a fundamental assumption of Scrum (and other Agile processes). So, you can't actually be doing Scrum and not have to deal with the problem of a changing system that requires constant design improvement.
...Well, you can, but you're system will eventually grow so complex that Scrum will cease to work for you (And then you will decide to rewrite it...)
Hello, Michael. On Wednesday, June 30, 2010, at 5:47:49 PM, you
wrote:
> Can someone give me a two or three sentence explanation of why refactoring
> is an essential part of agility and emergent design, why it is important and
> essential, and how much time should be set aside for the activity? It has to
> be simple and clear enough for non-techies to understand. Iım documenting
> what I think to be things we can do to improve our development process. One
> of the problems is that we are not refactoring.
Ron Jeffries www.XProgramming.com www.xprogramming.com/blog
Thousands of years ago, the first man discovered how to make fire.
He was probably burned at the stake he had taught his brothers to
light - Howard Roark (The Fountainhead, Ayn Rand)
Can someone give me a two or three sentence explanation of why refactoring is an essential part of agility and emergent design, why it is important and ...
Refactoring is essential because requirements inevitably change and therefore code inevitably changes to satisfy them. When code which adheres to principles of...
We reduce errors and the future cost of change when we do the simplest thing that could possibly work. But our first attempt to solve a problem will be a bit...
I agree with everything you say. However, you are describing the advantages of TDD as a whole and not of refactoring by itself. Refactoring is useful by...
Hello, Michael. On Wednesday, June 30, 2010, at 5:47:49 PM, you ... http://xprogramming.com/blog/why-is-refactoring-a-must/ Ron Jeffries www.XProgramming.com ...
That's a great article. The main thing it adds, that neither Michael nor I said, is that changing requirements are a fundamental assumption of Scrum (and other...
The case for refactoring doesn't depend entirely on the inevitability of changing requirements. Even with static requirements, my first coding/design attempts...
Hello, Michael. On Wednesday, June 30, 2010, at 7:14:54 PM, you ... Exactly ... ... I don't think it is academic at all. Even when requirements don't change...
... I don't disagree, but I think it is mostly semantics. I wasn't drawing a distinction between requirements that change and our changing understanding of...
Hello, Adam. On Wednesday, June 30, 2010, at 7:41:06 PM, you ... Well, refactoring isn't about requirements, though, is it? It's about design. And our...
... Yep. I can see how "changing requirements" has a certain amount of cognitive dissonance. There are two closely related ideas here: what the customer wants...
Ron, I was going to use that article of yours as a reference link, along with one by Martin Fowler. Neil Ford has a beautiful presentation about refactoring, ...
You're first mistake is trying to talk to executives about refactoring at all. They don't need to know about that any more than I need to know the details of...
Amen. The time required to refactor the code should be included in the estimate for the story. Executives asking for details below the story level are simply...
+1 Just as the execs really don't care if you use a for-loop. There really is not reason to ask for permission to do refactoring, its just part of how we...
I rather like that, since I've seen that argument (a major chunk or re-work/re-design being called 'refactoring'). Often there really is a need for re-work...
... Well if you can't find the original source you can credit me :-) I've said often enough too. Somethings just don't need a source. Cheers Mark *Mark...
Take a look at the auto industry. The vast majority of companies update their models annually, with major makeovers occurring every few years. Each refresh...
Listen and stop the BS. These lenghty dissertations trying to prove you know. Agile only make you look stupid. Take our local motor mouth. He knows nothing...
Offline 
Send Email