BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations Stop Refactoring!

Stop Refactoring!

Bookmarks
43:52

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.

About the conference

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/

Recorded at:

Jul 09, 2012

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • The aim of refactoring is not perfection

    by Marcos Antonio,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT