Re: [tlug] [OT] Good IT Resume

[Curt Sampson <cjs@example.com>]

On Sat, 28 Jul 2007, Josh Glover wrote:

> Well, why not keep a spec?

I do keep a spec. It's the code (which of course includes the tests).

> The spec tries to codify the things that code just cannot (or at least
> is not good at)....

Well, the wonderful thing about about computer languages is their
malleability. If something about the language you're using is preventing
you from documenting your spec. right there, change it.

Your example was amusing, but if implementing an optimization causes the
software to fail (and I can think of many situations where this could
be the case, though technically it's not just an "optimization" if it
changes the behaviour of the software in a way that introduces bugs)
then there there must be some way to test that the software is failing.
So your challenge, when the customer says "don't do Y because it will
break the software" is to write a test that proves the software isn't
broken that way.

Later, if someone tries to implement that, they'll run the test, the
test will helpfully show you just how the software is broken, and you
won't commit that piece of code.

> > If you're looking at code that seems to be doing something odd, just
> > "fix" it, run the tests, and you'll quickly be shown the exact test that
> > tells you why it's odd.
>
> Maybe.

Right. And maybe the spec will also explain why the code is odd, and
maybe you'll read it, and maybe you'll succeed in that particular
attempt at the manual process of comparing the code and the spec.

Keep in mind, I'm not saying that your process can't work. I'm just
saying that I can automate some of the stuff you do manually, and I'm
also claiming that once you teach a computer to do something, it can do
it over and over again more reliably than a human can.

What you appear (to me) to be claiming is that there are certain things
that you can't teach a computer to do, and I'm saying that I do teach
computers to do these sorts of things all the time.

> > If you're wondering about the system design, read the code.
>
> Wrong answer! Why should I have to read the code, which will take a
> long time and could be quite difficult....

If that's the case, fix the code so that the salient points can be read
quickly and understood without difficulty.

There should certainly be no need to read every line of a well-written
10,000 line application in order to understand what it does and how
it does it. Do you read the library of fopen() to find out what an
application reading a file does?

> The bottom line is this: the spec shows how it is supposed to work.
> The code shows how it does work. When the spec is kept up to date, any
> differences between spec and code mean a bug in the code.

Or a bug in the spec.

> Is your code bug-free? 'Cuz mine ain't.

No. Are your specifications bug-free?

> Because the customer reviews it.

My customers review my specs, too. Only they often find it easier
because it's on an index card instead of being a ten page document. My
customers also sometimes review my code. Sometimes they even write it.

> 1. A project I recently finished added well over $100,000 (US) a
> *week* in incremental revenue. Had I needed to make late changes and
> the project was delayed a week because of it....

And what if the project was instead delayed a week because you spent all
that time writing a specification?

I'm quite familiar with time vs. money tradeoffs. That's why I develop
stuff the way I do, and why I generally don't do heavy specifications.

> > You may not know how to do this, but I assure you, it can be done. And I
> > can teach you how to do it, if you wish.
>
> I will dismiss that as arrogantly tactless, and not a personal slight,
> as it seemed in the harsh light of midnight.

*Shrug*. I do XP coaching. I think it's more tactless of you to argue
that what I do can't work when not only do I have plenty of examples of
it working successfully, but I can even show you how to make it work
successfully for you, if you're willing to set aside your predjudices
and learn.

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