C[omp]ute

From: andrew cooke <andrew@...>

Date: Fri, 22 Mar 2013 19:00:05 -0300

[This is partly esprit d'escalier and party notes to try again on Monday,
because I had this conversation yesterday and completely failed to make my
points.]


So, yesterday, I was talking to someone (let's call him S) about testing.  And
why S's employees didn't do it (or various other "best practices").

S argued that he was making progress, but that it was difficult because adding
extra time for tests, CI, etc made prices higher, when the client was already
very demanding.

At this point maybe it would have good to ask S why he thought I wrote tests.
I promise it's not because I find them a good way to spend extra time.  In
fact, I think they help me do my work faster.

Which perhaps sheds some light on S's problem.

If good (excuse my lack of modesty here; I'll return to this below) engineers
use tests to do their work faster then of course the client is going to be
unhappy.  Why are they being charged more for something that means less work?

Now S isn't dumb.  There's a reason he needs more time for tests.  The reason
is that currently his engineers don't use them.  So this time is, effectively,
on-the-job training.  That's the positive take.  The negative take is that the
tests are checklist items that his engineers will do without conviction or
understanding - rote work with little gain.

Which is putting the horse before the cart.  You can't go to a client and say
"my engineers suck, so I am going to charge you extra."  Instead, S needs to
improve his engineers.  And fast.

So what to do?

One thing you can do is ask the engineers why they don't test.  One answer I
got was that there was never enough time.  And I can undestand this.  If
you've never used tests it can seem counter-intuitive that they save time.  So
maybe what that engineer needs is the encouragement and freedom to explore a
little: give him some extra time so he can learn to save time in the future.


Now, back to my modesty.  In my previous job I was just an average programmer.
What I was praised for was my moderation - that I knew when to compromise, and
how to find a balance between "best practices" and "getting shit done".

Which is ironic, because yesterday I found myself shouting at S, in the role
of the extremist developer, foaming at the mouth about lack of standards.


On Monday I hope I have the energy to try again.

Andrew


PS. One more statement I forgot to pick up on: "I write tests, but only use
them to solve the problem at the time".  Which is doing 99% of the work for
only 50% of the gain.  So I really need to explain how tests help refactoring.