Re: [tlug] [OT] Good IT Resume

[Curt Sampson <cjs@example.com>]

On Thu, 26 Jul 2007, Josh Glover wrote:

> The customer is happy, and the specification has been specified, but
> not codified. What happens when you come back to that project in six
> months and you have no record of the process?

Um...nothing bad? I'm not sure why you would really need a record of the
process, but I suppose if you're worried you could keep a diary.

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. Or, if performance was a consideration, run the
benchmarks before and after and you may see why something was done a
certain way. If you're wondering about the system design, read the code.

> I also like a iterative specification process. The difference is that
> I capture the process in a document, which evolves with the project,
> so when my work is done, the document reflects the latest state of the
> specification.

Unfortunately, you now have two specifications, and you have to make
sure that you update the paper one as well as the code one. And the code
"specification," has executable tests, at least; how do you make sure
that the paper one is correct after you modify it?

> Then in six months when I need to change something, I
> have a great document that tells me precisely how the code is
> *supposed to* work.

I have a full set of executable tests that not only tell me how the code
is supposed to work, but even test it for me to make sure it really is
working that way.

> I agree with this in spirit, but if you are really saying that late
> changes are cheap, I think you are smoking something good, and I want
> a toke.

I'd love to give you one. Yes, late changes are cheap in my projects.
I've got projects where I've ripped the heart out of the code and
completely redesigned it in the week before before a release, and this
does not cause problems.

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.

> How is a change cheap if it means altering your basic assumptions (and
> the code that implements said assumptions)?

Well, ok, some changes may not be cheap, but they're no more expensive
than it would have been to make the change closer to the beginning of
the project. And often you just don't have enough experience to figure
out what something's supposed to look like until you've done a fair
amount of implementation work on it.

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