Re: [tlug] Giving a program priority briefly

[Curt Sampson <cjs@example.com>]

On Tue, 12 Jun 2007, Darren Cook wrote:

> Yes. You could argue that refactoring before you know what you
> functionality you will need next is like optimizing without first
> profiling your code.

I don't think I'd go that far. There's not infrequently some "obvious"
refactoring that can be done at "clean-up" time after you've just
finished implementing a feature, and doing that generally isn't harmful,
and is often good, since you can usually do it quickly because at that
point you quite well rembember the structure of the code and what the
heck you're doing.

But there is a parallel in the sense that any refactoring done on code
that's not touched again is a waste of time, since the added clarity
does you no good if nobody ever sees it and saves time because of it
later.

> Stepping back in to the real world though, 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.

I don't consider that refactoring at all: defining a published API is
design, pure and simple. (And it's definitely design that wants to be
put off to as late as possible.)

I've always wondered what the best way is to deal with published APIs.
Mostly, in the end, I've ended up deciding that users get agile or get
stuck, and change away as I see fit, though I've experimented with
maintaining an API compatability layer on top of the library itself
that lets users of an older version upgrade to a newer one with minimal
changes.

It affects us internally, too, since we have half a dozen different
production websites running on various versions of our (Starling's)
framework. Mostly we've been trying to build tools that let us upgrade
parts of these sites as quickly as possible, do it on a frequent basis
even for sites that are not currently under development, and put the
cost down to "API research," since at least it does give us a lot of
different examples of how the API is used.

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