Simplicity or Optimization?

9 August 2006 (Wednesday)

A comment from a colleague on the importance of the experience programmers bring when refactoring to good design

“Something that doesn’t get mentioned about refactoring to a ‘good design’ is that there is a lot of experience brought to bear about what is good. ”

Given that my experience as a programmer (like others’?) is a compound of years of dubious programming practice (premature optimization*, doing-the-most-complicated-thing-that-I-could-possibly-think-of*, and building things I never needed*) together with plenty of more recent (but overlapping) self-reeducation into agile (test-driven, continuously integrated, issue-tracked, repository-managed, performance-profiled dependency-injected and occasionally even pair-programmed) development, how can I be sure where my gut feel and sense of smell* are coming from and therefore driving the development. Can I (therefore) trust myself? Yes, of course, all these practices help, but (as pointed out) experience is critical in distinguishing good from evil.

So I’ll try to think it through with an example…

For example, in developing sodaplay2, “items” (like an application, a model, an article or whatever) have (canonical) URIs. In the sodaplay2 prototype, I (badly, quickly, hackily) injected the base uri into the item as it was created, so it had a nice helpful uri method (which turned into about three or more methods per item class as the types of uri (about, launch, xml (machine readable) icon (png/html), edit, add property etc.) started to multiply… In the more slowly* and carefully develped (and test driven) real code, a UriEncoder service emerged which would operate on items. The items then just needed to collaborate with the UriEncoder. So far so good.

What I came up with was that the item would have a method appendPath(StringBuilder pathBuilder) where they are passed a StringBuilder and asked to add their pieces to it. Of course we could just have had them return the path segment as a string – but they would then construct a new stringbuilder and convert it back to a string. So my first worry – am we prematurely optimizing? We haven’t profiled the webapp to find out how important this is. If I weigh the tendencies: a string-returning method may be more useful in the future (YAGNI alert); a StringBuilder solution is more performant than a String one (premature optimization alert); the UriEncoder just needs to build a string – it doesn’t need the path as a string (the simplest thing, then, is the append function). So maybe all that went through my head when defining the inteface between the item and the UriEncoder and I worked out the simplest thing. Maybe I just got lucky, that time. And of course, this is one small decision in the development and emerging direction of this body of code (sodaplay2).

I don’t think I’ve gone very far in answering the question of how to trust one’s checkered experience and conflicted gut-feels. Maybe this (and a limited amount of experience with pair programming) tells me why pair programming can be helpful – or to put it into a Kubricism: “Pair Programming, or, How I learned to stop worrying and just write some code “.

References:

  • Knuth/Hoare: “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” (e.g. see
    Premature Optimization as an anti-pattern, however Naive non-optimization considered harmful).
  • YAGNI – YouArentGonnaNeedIt
  • DoTheSimplestThingThatCouldPossiblyWork
  • Fab chapter (by Kent Beck) on “code smell” in Martin Fowler’s Refactoring
  • Tiptoeing into Cavell’s “The Claim of Reason”, I rather liked the quote from Wittgenstein to the point that philosophy done well is about being able to think slowly enough. This just now brought to mind the suggestion by a colleague (when talking about relative speeds of development in java-on-spring vs ruby-on-rails (e.g. see “Beyond Java” Bruce Tate)) that there isn’t so much a need to increase speed of software development as to slow it down! (paradoxical that – especially from the point of view of ‘agile’ software development, but I think there’s something profound worth digging about here. Not that it’s discouraging me from learning rails nonetheless!).
Advertisements

2 Responses to “Simplicity or Optimization?”


  1. I really like the Wittgenstein quote too, and that “slow development down” thing rings a bell in me.

    Too many times i find myself having to redo lots of code because of the initial necessity of quick results.

    I guess I must slow down to speed up.

  2. Garry Says:

    hey tim,

    saw the title of this whilst on the homepage (just reading your process doc) and just knew it was yours.

    I recognise your train of reasoning above—“am i over/under designing?”—it’s been driving me bonkers, almost to the point where i don’t enjoy programming any more because of it.

    your “relative speeds of development in java-on-spring vs ruby-on-rails” made me realise that the most important thing isn’t speed so much as your ability to keep clarity of vision. you know, the “why the hell did i start doing this in the first place?” question that can hit you when your internal code stack has built up just a little too high.

    Experience enables you to keep hold of the big picture whilst counting change. You’ll only realise something’s a mistake once it’s already too late anyway. Maybe we need an acronym for this too, hang on… It’s Not A Mistake Until It’s Too Late Anyway: INAMUTITLA. has a certain ring.

    sometimes you need to go fast, sometimes slow, it depends, i find, on how excited you are by the functionality you’re about to unleash and also on your past experiences with the code your engaged in writing. sometimes you just know it’s going to be a bitch, sometimes you know you just don’t really understand the problem and it’s tipsy toesy. sometimes you just need to quickly sketch something in before your inspiration fades.

    my recent, pleasant, experiences with ROR have mainly shown me how nice it is to have a language that doesn’t overload you with How You Should Be Doing It (HUSBDI) but just lets you Get On With It (GOWI).

    I think that java, in it’s strictness or its culture, generates the feeling that there is some purer, cleaner, more acronym compliant way of doing what you’re doing, but somehow you haven’t figured it out. Hence you start to see the trees and not the wood.

    My use of ROR was pretty non-standard so i acutally found the “weblog in 15 minutes” bootstrapping jelwelled sombrero framework more of a tit encrusting corset, but ruby in itself is a really fluid language. It does a good job of being transparent and letting you see where you’re going and choose what speed you go at.


Comments are closed.

%d bloggers like this: