Re: [tlug] Giving a program priority briefly

[Curt Sampson <cjs@example.com>]

On Tue, 12 Jun 2007, Stephen J. Turnbull wrote:

> Nonsense.  Some optimizations are obvious and costless in readability,
> as are some refactorings.

Let's not let the condemnations get too harsh here. Optimization is
all about improving performance in the end, right? So even if the
readability cost is zero in the end, it's still not worth spending
the time on optimizing something unless it actually makes a noticable
difference in the program's performance, and though long experience
we've all learned that in all but the most obvious cases this means
you need to measure that performance difference though some form of
profiling.

This is why I think that the parallel between optimization and
refactoring is not particularly well drawn.

> One does not plan capabilities required for unknown features in 3
> minutes of design (at least not with any degree of usefulness)....

Not for unknown features, perhaps. But given that you know what
particular feature you want, planning the implmentation of any given
part of it can often be a three minute job. Any more time than that
is often wasted, since five or ten minutes of attempting to code it
will often tell you far more than another half hour of thought and
discussion.

I won't say I don't do a lot of planning; I'm sure that if I used a
stopwatch and added up all the time I spend "planning" over the course
of a week, it would add up to quite a lot. But it's very spread out.
Perhaps you might think of it as "just in time planning"; do enough to
make good use of the knowledge you have and allow you to start coding
again, and at that point do some testing to see how your plan works.

> Time and motion studies[1] show that engineers do focus fairly well on
> one of those functional areas at one level of structure for up to
> about 10 minutes at a time.

Just incidently, pair programming changes the dynamic of how one
"focuses" on things quite a lot.

> The thing that impresses me is that not one of you mentions
> *specification*...

That's because, for typical business and productivity systems, a level
of specification greater than "arm-waving" is, in the majority of cases,
useless. Most clients, product managers and even developers who are
also the product managers don't know all that well what they want, and
thinking about it doesn't generally help that much. It's very often
faster to kick around some ideas, do a rough implementation, examine the
result, and run round that loop a few more times than it is to try to
write a spec.

> ...and in particular *listening to clients of your code*.

I would consider porting old apps to new versions of Starling's web
framework on a regular basis to be doing exactly that. Does the code
become more comfortable? Do previously hard things become easier? Is
application-specific code replaced by generic code? Does the application
get smaller? All of these things are indications that the framework
or library is going in the right direction, and their corresponding
opposites indications that it's going wrong.

> > ...if you need to publish an API that programmers outside your
> > immediate control will use, then some pre-release refactoring based
> > on guessing future needs may be a good idea.
>
> About which Victor Vyssotsky says: "[Developers] won't tell you they
> don't understand [the specification]; they will happily invent their
> way through the gaps and obscurities."

Indeed. Which is why you need to get out there and work with them, and
code with them, to see what they really do. It's exactly analogous to
watching a user really use a spreadsheet, rather than just asking him
what he wants.

> My conclusion is that the name of the game is specification.  The rest
> of the work, you do what comes naturally and it will work out.

Unless by "specification" you mean "code in production" (which, after
all, is the real "specification" by which the computer decides what to
do), I think we're in disagreement here.

The question is, how do you get to having the right code in production,
and thinking about it I've found, in the majority of cases, is much less
effective than doing it and then fixing the results.

> But at higher levels, effective workers generally specify, plan, do,
> with formal documentation at each step.

My usual "formal documentation" is a pile of index cards with roughly
sketched out ideas on them ("stories"), and a lot of conversation with
the client, every day.

I don't expect anybody to be convinced by this post, BTW. In my
experience, it's the sort of thing that's very hard to believe until
you've participated in it yourself and seen it be successful. There are
also a small number of relatively obvious examples of situations where
you want to be rather less carefree than this, and people tend to hold
up those few examples as proof that the whole concept could never work,
anywhere.

cjs
--
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
Mobile sites and software consulting: http://www.starling-software.com