Re: [tlug] Giving a program priority briefly

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > 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.  [...]  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.

*guffaw*  You didn't read what I wrote, although you quoted it.
Twice, in fact. ;-)

 > 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.

Which are the ones that Darren was talking about.  My point was that
you and he were talking about different levels.  He denies that, but
your response suggest you agree with me.

 > > 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 after that, it's called the "reference implementation".  Ie, it's
a spec.  And your clients demand that you conform to it, don't they?

 > > ...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.

Me too.  All I'm saying that that it's worth mentioning, and a more
practical division of discipline than "refactoring, functionality,
optimization" if you plan to talk about what needs to come first.

 > > 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.

Sometimes I do (see above).  Mostly I mean the user manual or the API
reference, as the case may be.  Anything that the client can point to
and say "you promised, but your code doesn't deliver".

 > 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.

Mine is VC log messages.  The point is that it's there to refer to
later when cognition turns dissonant, when you look at your own code
and go "WTF?!"

 > 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.

The authors I respect on the matter would look at the process you
describe, and say that in general your specification, planning, and
implementation activities are well-defined in the sense of
"repeatability".  I would guess you would start to run into problems
if you tried to scale this process into a team larger than 5
programmer members.

I know that a team as small as XEmacs's can easily benefit from a more
formal approach (although it seems highly unlikely it ever will :-( ).