Stop Refactoring!

Recorded at:

Summary
Nat Pryce considers that we cannot write the perfect code because it is never fully prepared for the coming change, so he suggests embracing impermanence & continual imperfection.

Bio

Nat Pryce is author of "Growing Object-Oriented Software, Guided by Tests" and developer of the jMock mock-object library. He is an early adopter of XP, a contributor to several open source libraries and tools supporting TDD, and one of the organizers of the London XP Day conference. Pryce has received his PhD from Imperial College.

For the second time we are launching the GOTO Copenhagen conference in May 2012 after a successful execution in 2011. GOTO Aarhus has been an annual event in Denmark since 1996 and attracts more than 1200 participants (formerly known as JAOO). The target audience for GOTO conferences are software developers, IT architects and project managers.http://gotocon.com/

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.

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.

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.]

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.

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.