> This is dragging into a usual pro/con XP debate - and I
> really don't want to go there. I've seen XP's techniques
> work well but I'm not inclined to push them on people who
> don't fancy them. If you're interested in discussing this
> further I'd suggest one of the XP groups.
>

Well, the interview was billed as "Fowler gives his views on many topics, including refactoring, design, testing, and extreme programming", and this is a discussion forum based on that interview. How could a discussion on the pros and cons of XP be out of line here? Likewise a discussion of levels of explicitness in code. One might say that you brought you it up :-/

What is the point of this forum if it isn't to discuss points made during the interview?

> Martin

-Mike

We've pretty much run this thread dry. Summing up I'd say that you are inclined to do data driven approaches much earlier than I am. Clearly also my choice of example hit a sore point - for which I apologize but defend myself by saying that any example simple enough to follow is going to be simplistic.

There's also a difference of opinion on ease of refactoring into a data driven approach. I find it quite easy to write very concrete code and rapidly generalize it - to a data driven style if needed. You would prefer to start data driven from the beginning.

Martin

> I'm forced to completely disagree. One given instance of
> an explicit piece of code is easier to understand. "N"
> instances of code 99% the same is not easier to understand
> - even it's only three instances - because to understand
> the whole mechanism you have to look at all the
> instances.
>
That's true, but I don't think that's the kind of "explicitness" we are talking about. Perhaps you have three methods whose names each explicitly say what they do. That makes code calling them more explicit. But if those methods do 99% of the same thing, then they that 99% code should be factored out as one private helper method (also with an explicit name). Now it is a judgement call whether to collapse the three public methods into one public method with a parameter. The point of the explicitness argument I think is simply that part of the way you make that judgement is by asking yourself what appoach (three methods versus one) will make the client's code easiest to read and understand, and that method names that explicitly say what they do tend to improve readibility.

> Worse - you've still overlooked the cost and effort of
> programmer time. Explicit solutions always need a
> developer to make any sort of change. That's not only
> inflexible, but expensive. In NYC, where I work,
> developers routinely get 6 figures or just below. The
> last person I want fiddling with a discount rate is a
> programmer.
>
I wouldn't equate explicit with non-configurable. You can have a highly configurable system from the outside whose code on the inside is explicit. Explicit doesn't mean you don't use data. It just meanst that when I look at your code it kind of tells me what it does by the way you've partitioned things and named them.

> I've been writing configurable code for so long that the
> complexity no longer seems all that difficult for me - but
> of course others may differ. The reason I go down that
> route is that I can't forsee all possibilities. Hard
> coding seems great until a production problem crops up.
> In my world, those problems can often be resolved by an
> expert tweaking the right parameter and restarting the
> process. In the world you describe, you need a
> coding/QA/deployment cycle.
>
The funny thing is that the reason I prefer to not make things configurable unless I know already they need to be configurable is that "I can't forsee all the possibilities." I agree with you that if a production problem crops up that can be solved by tweaking a configuration parameter, then you've gotten a good return on your investment of making that parameter configurable. But what the the 300 other parameters you made configurable that never needed to be configured? What about the 3 parameters you didn't make configurable that did need to be configured?

One way to deal with our inability to predict the future is to make things as generic and/or configurable as possible. Another way is to just solve the specific problem at hand and add functionality in the future as it becomes required. I see these as two ends of a spectrum, not an either or choice. I get the sense that the XP camp advocates never doing anything beyond solving the specific problem, and I do find that advice to be a bit extreme. But my own way of dealing with uncertainty (the inability to see the future) is to lean heavily towards the specific solution end of the spectrum. I am conservative about adding any kind of functionality or genericity that I don't know I actually need right now. I do it sometimes, but usually I don't. Because I'm not good at predicting the future, the risk is high that I won't get a sufficient return on the investment of time spent putting in generic functionality that I don't actually need right now.

> > I'm forced to completely disagree. One given instance
> of
> > an explicit piece of code is easier to understand. "N"
> > instances of code 99% the same is not easier to
> understand
> > - even it's only three instances - because to
> understand
> > the whole mechanism you have to look at all the
> > instances.
> >
> That's true, but I don't think that's the kind of
> "explicitness" we are talking about. Perhaps you have
> three methods whose names each explicitly say what they
> do. That makes code calling them more explicit. But if
> those methods do 99% of the same thing, then they that 99%
> code should be factored out as one private helper method
> (also with an explicit name). Now it is a judgement call
> whether to collapse the three public methods into one
> public method with a parameter. The point of the
> explicitness argument I think is simply that part of the
> way you make that judgement is by asking yourself what
> appoach (three methods versus one) will make the client's
> code easiest to read and understand, and that method names
> that explicitly say what they do tend to improve
> readibility.
>

I concur completely in those areas. I think part of the mismatch is not based on the interview, but one of the supporting documents (Mr. Fowler's essay on explicitness). In that document the view is very much (and this is a paraphrase, not a direct quote) "do exactly what the user story says, do not extrapolate, and make it as concrete as possible". The last example given is the discount plan example, and I disagree most heartily with that example. There, the discussion is about a common business component (discount plans), of which there are several variations (in the example, three). In that sort of situation the explicit code is a cop out. You're making someone's life more difficult down the road on purpose so you can get this iteration in with minimal work. I think that's wrong - not morally, but in terms of overall work on a project. In short, the coder is just _asking_ for trouble by being explicit in that sort of situation.

> > Worse - you've still overlooked the cost and effort of
> > programmer time. Explicit solutions always need a
> > developer to make any sort of change. That's not only
> > inflexible, but expensive. In NYC, where I work,
> > developers routinely get 6 figures or just below. The
> > last person I want fiddling with a discount rate is a
> > programmer.
> >
> I wouldn't equate explicit with non-configurable. You can
> have a highly configurable system from the outside whose
> code on the inside is explicit. Explicit doesn't mean you
> don't use data. It just meanst that when I look at your
> code it kind of tells me what it does by the way you've
> partitioned things and named them.

I don't think that's so much as explicit as just plain well written. If you re-read Mr. Fowler's essay I think you'll see that he's directly arguing against data-driven code unless a powerful argument is made for it. Explicit there means very, very explicit, to the point of hard-coding your discount rate for the "blue plan" (or whatever) directly in your code at 15%. Perhaps the example was just a really bad one from my perspective, having seen precisely such code push projects past deadlines and over budget because someone took a very, very short term view of the requirements.

It's even worse in the XP sense. Given rotating pair programmers working on different stories at different times, the developer is in effect foisting the effort to make the code configurable on some other developer at a later time - when the system is more complex and by definition harder to refactor. See the essay by Mr. Fowler's company which dissects a large project which took the XP approach, and how following requirements literally at every stage got them in to trouble.

The problem I really have with this flavor of expclitness is the concept of religiously following the requirements of this iteration (possibly out of many, many iterations) and refusing to apply any forsight at all. Mr. Fowler can assert all he wants that it works out somehow in the end, but real case studies say precisely the opposite.

-Mike

> We've pretty much run this thread dry. Summing up I'd say
> that you are inclined to do data driven approaches much
> earlier than I am. Clearly also my choice of example hit a
> sore point - for which I apologize but defend myself by
> saying that any example simple enough to follow is going
> to be simplistic.
>

Reading your most recent interview, I'd say our approaches match somewhat, but differ mostly in timing. I, too, always start out with an explicit approach in the beginning. This helps me wrap my mind around the problem in full and really test out all the boundaries of the problem space. The difference is that I'll rarely release that code. It's my "fooling around code". Once I've gotten something working with the bailing wire and duct tape, I throw it all away and write a more appropriate solution from scratch. It's not so much refactoring as writing a proof of concept to figure things out, throwing 90% of that out, and then writing the real thing.

As you mentioned, this seems wasteful but in fact wonderfully concentrates the mind and figures out solutions to problems fast. But I think it's important not to release that conceptual code but something that benefits from what you learned. From what I've read, you seem comfortable releasing stuff into an iteration that has alot of "explicitness" in it, and leave it to a later time to refactor when more information becomes available. I've tried that approach, and it's burned me more times than I care to admit. Taking the time to look ahead just one or two iterations, and applying hard-won business knowledge from past projects, means make the code a bit more configurable up front to avoid several painful refactors down the road.

> There's also a difference of opinion on ease of
> refactoring into a data driven approach. I find it quite
> easy to write very concrete code and rapidly generalize it
> - to a data driven style if needed. You would prefer to
> start data driven from the beginning.
>

I think the difference is deeper than this. You have repeatedly stated that refactoring is an on-going process that never stops (yes, this is a paraphrase). I prefer to rapid prototype a proof, chuck it, re-write and then be satisified with the result until several iterations later when the well-docmented "pain factor" gets too high. In my own projects, constant refactorings are not practical because all the details of a given component or sub-system do not stay fresh in my mind indefinitely. Because of this, constant refactoring means I'm going to be re-structuring code that's a bit fuzzy to me - and I believe this is a bad thing. In short, I prefer to take costs up front. If I make a mistake doing that from time to time, fine. But most of the time that up-front work pays off down the road when crunch time comes and final deliverables loom.

In short - never, ever put the hard work off for last, because that's when you'll have the least amount of time to do it.

> Martin

-Mike