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 “.
- 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
- 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!).