Spacing conventions

[Steve D'Aprano]

On Fri, 29 Sep 2017 03:01 pm, Chris Angelico wrote:

> On Fri, Sep 29, 2017 at 2:38 PM, Steve D'Aprano
> <steve+python at pearwood.info> wrote:
>> On Thu, 28 Sep 2017 03:56 pm, Bill wrote:
>>
>>> I worked in maintenance programming.  You got the hand you were dealt!
>>> And you weren't allowed to "improve" the code unless the customer
>>> contracted you to do so.
>>
>> How do you tell the difference between a bug fix and an code improvement, if
>> the behaviour of the program remains the same?
> 
> If the behaviour remains *exactly* the same, then it's a code
> improvement (aka a refactoring), not a bug fix. Or, looking at it
> another way: if there is absolutely no change to behaviour, how could
> you tell that there was a bug in it?

Well obviously you fix the bug, not just refactor and keep the bug. Sorry if
that wasn't clear enough.


> And yes, trying to convince a customer that it's worth paying for
> improvements that don't change anything visible is hard.

The point of refactoring is to make it easy to fix the bug:

"Two hours refactoring, plus thirty seconds to fix the bug; versus 18 hours to
fix the bug without refactoring."

Plus or minus six weeks on each of those times *tongue pressed firmly in cheek*


But more seriously, I'm not suggesting you refactor the whole code base. You
only refactor the bit you are touching *right now*. That's especially relevant
for Bill's comment about loops which are hundreds of lines long. There's a bug
somewhere in the loop, and finding the bug is going to take many hours. So
spend half that time cleaning the loop up by factoring bits of it out (if
possible!) in order to (1) understand what the loop does, and (2) simplify the
debugging process.

Technically its an improvement. But its not a *functional* improvement, which is
what people usually mean when they say no improvements, only bug fixes. It is a
code-quality improvement[1] *necessary to fix the bug*.

Perhaps not strictly necessary. You could spend five times as long fixing the
bug (and introducing two new ones) by *not* refactoring.

Of course, I understand that sometimes there are political reasons why you can't
do that, and they're not always bad reasons.  But I bet that for *most*
customers, if you give them the choice between:

(1) Minimize the number of lines of code changed; or

(2) Minimize the number of dollars on the invoice

they'll usually prefer (2).

Don't try to sell them on code refactoring as an investment for the future,
they're not interested.

Don't try to convince them that they need to reduce technical debt. Debt is
something for the next generation to worry about[2].

Don't even mention refactoring. That sounds like an improvement, and they said
they don't want improvements.

But even the most unreasonable client will surely understand that before you can
fix the bug, you have to find it, and that requires understanding the code.
Cleaning up the *immediately relevant section of code* (giving variables
meaningful names, extracting common functionality, etc) is part of the
necessary process of understanding the code and finding the cause of the bug in
the shortest possible time, and the fact that you end up with cleaner code and
less technical debt at the end is a happy accident. That's not why you did it,
so technically all you did was fix the bug, exactly as told.

(They didn't tell you *how* to fix the bug. If they knew how, they wouldn't need
you.)

But, as always, this is risky if you don't have a good test suite.



> Which is why 
> a lot of companies end up merely paying interest on their technical
> debt, and never paying off any of the capital.
> 
> ChrisA


[1] Maybe. The downside of piecemeal refactoring is that sometimes it increases
complexity until you pass a critical point and it starts decreasing it again.

[2] And that's not always a bad thing. Debt is not always bad: its money that
you can invest in building your infrastructure or startup or keeping a roof
over your head until you find a job, and it makes sense to delay paying off the
debt until you have a better income stream that will afford it more easily.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.