Stop Refactoring!

The aim of refactoring is not perfection

by Marcos Antonio, Jul 09, 2012 05:54

If we were going to stop doing a thing because we cannot achieve perfection in that thing, we would stop doing everything. Perfection doesn't exist in this world. But excellence does; that's what we aim with refactoring. Refactoring is a proven technique.

Interesting perspective

by David Smith, Jul 10, 2012 01:51

I've come across many immovable designs before, so I know your pain. But to the point from the audience that "the abstraction could be wrong" is valid. Yes, object models change with requirements, but that's not the point. I find that the two major reasons that object models become immovable are:
1) class hierarchies don't conform to the Liskov sub-type ideal.
2) interfaces are too generic -- they should be small specific.

Just because a system has been heavily factored doesn't mean that it was refactored well.

The last comment you made about how the system in question was oriented towards a functional design. I have been an avid FP hobbyist for some time and have made it a point to learn enough Erlang, Haskell and Clojure to write some very pretty code. But I don't have enough experience to know how to properly design large business domain systems in those languages. I suspect if you concentrate too much on the high-order functions and not enough on the proper use of the polymorphic abstractions (type-classes, multi-methods, etc.) you will have problems.

In any case it was a thought provoking presentation. Thanks for sharing.

Quite a wishy-washy presentation

by Conor Moran, Jul 10, 2012 08:52

Maybe Nat is right. Perhaps too much refactoring is bad in the way that too much of anything is bad....maybe...
However I have yet to work on this ideal, conceptually perfect, system. Most of the code I look at is often at entirely the other end of the spectrum.

As for the lead-in where he describes a guy making a system beautiful, and then discovering that the new feature is very difficult to add...more detail on that part is definitely needed. The presentation code be more concrete then.

For me it's probably like all aspects of life, balance is always good. Even for the health conscious, a little splurge every now and again might be just what the doctor ordered.
With design, there are always trade-offs, there is never perfection, simply suitability with specific qualities in mind (often in a circumstance where different/competing qualities are important).
It must be strong but look dainty.
It must be secure but fast.
It must be maintainable and adaptable. [Seems to me this is the one that Nat hits upon - for me refactoring is very much about maintainability, I guess he's arguing that it can inhibit adaptability. My "common sense" gut doesn't necessarily agree with that.]

Wabasabi objects are recognizable

by Adam Nemeth, Jul 10, 2012 04:49

I know, I shouldn't feed the troll....

While our industry surely has the tendency to give up all sanity, and accept that we don't understand anything, I'm prone to account this for people who are too stupid to understand their own program, and work way beyond their actual cognitive borders, so called code-monkeys, mostly with no scientific background and are certainly limited by what kind of blog posts did they read as a substitute for books.

But someone with a PhD likely doesn't work beyond his cognitive borders and that software design is well within these bounds, so that isn't the issue here.

I'm yet to see a wabi-sabi object, which is multidimensional, multifunctional. I mean, yeah, a teapot can be weary, but it's still a teapot, and it's beauty lies behind the recognizability of being a teapot.

Now if you don't refactor, you'll have a class named Mud, which will act as a teapot, or worse, a class named Teapot, which will act as a building.

And that won't be wabi-sabi.

Of course, single-purpose enterprise applications are hard to find, but this doesn't apply to class-level: they can be, and they are usually a bit weary, yes, but in a good code, they usually still do their purpose in a recognizable way.

Alas, if they'd ever become hard to use, it's better not to have emotional bonds to them, and use it anyway (like wabi-sabi), but I guess it's better that in case they have too much shortcomings, we decide to get another one instead of them. Japanese do this anyway when not drinking tea, but using an automobil or such.

And that'd be refactoring, yes.

A system, is a system. A teapot is an element of a system, a full teaset to do a gong-fu cha consists of about 12 elements (and I don't know how muhc you'd need for a matcha ceremony). If any of the elements break, or they just can't fill their purpose anymore, we're likely to exchange them.

Oh, and btw, please: PHP devs DO argue a lot about how php-like their code is. Leave this out from your talk next time.

Dangerous

by Bad Ninja, Jul 15, 2012 11:47

This is really dangerous information for the following people:
1) Recent college grads
2) Impatient programmers
3) Incompetent programmers
4) Programmers who are reluctant to evolve.

Don't give someone who's proven to do bad things a license to do bad things.

maybe it's refactoring too early that's bad

by Bjorn Hansen, Jul 17, 2012 09:25

Seems like he's described refactoring as making the code beautiful for what it is right now, without knowing the next thing you want to add, but I viewed refactoring as changing the structure of the code without changing functionality so that it's easy to add the next thing *after* you learn what that thing is. In other words, if I have a piece of software that is working now (passes all tests etc), I probably shouldn't touch it. Only once I need to add something new do I refactor it to a design that fits the new functionality (and verify that it still works exactly the same as it did before), and *then* I add the new functionality.

Presentation is not proper

by rajesh parab, Jul 18, 2012 04:47

i think he could not presented properly what he wanted to say.

instead of doing stop refactoring he should talk about safe refactoring.