A design problem I met again and again.

[andrew cooke]

Emile van Sebille wrote:
>>> Whether you (generic you) choose to do so or not is a separate issue.
>
> Also agreed - and that is really my point.  Doing so feels to me like
> continuing to look for a lost object once you've found it.

i can see your point here, but there's two things more to consider:

1 - if you do need to refactor it later, because there is a bug say, it
will be harder to do so because you will have forgotten much about the
code.  so if it is likely that you will need to refactor in the future, it
may pay to do some of that work now.

2 - if someone else needs to work with the code then the worse state it is
in - even if it works - the harder time they will have understanding it. 
which could lead to them using or extending it incorrectly, for example.

both of the above fall under the idea that code isn't just a machine that
produces a result, but also serves as documentation.  and working code
isn't necessarily good documentation.

i don't think there's a clear, fixed answer to this (i don't think "stop
refactoring as soon as all tests work" can be a reliable general rule any
more than "refactor until it is the most beautiful code in the world" can
be).  you need to use your judgement on a case-by-case basis.

in fact, the thing i am most sure of in this thread is that 15000 lines of
code in one module is a disaster.  the likelihood of that being ok seems
so small, compared to all the other uncertainties in software development,
that i cannot see why people are even discussing it (well, i can
understand, because human nature is what it is, and software development
seems to attract a certain kind of pedantic, rigid mind, but even so...)

andrew