Re: [tlug] [OT] Good IT Resume

["Josh Glover" <jmglov@example.com>]

On 28/07/07, Curt Sampson <cjs@example.com> wrote:

> 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).

In my environment, I consider that unacceptable. Obviously, it works
for you. I would love to hear from XP advocates working for large dev
organisations about how it works for them.

> 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.

This is reasonable, but what if the engineer has already spent lots of
time implementing the "optimisation", then he runs your test against
his new code, and it fails, and he finds out what he could have found
out in 30 - 60 minutes by reading 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.

We are in complete agreement about the benefits of automation, but
apparently we disagree on the limitations thereof. Perhaps this
discussion should be deferred until I post an example spec, then you
can XP-ify it and prove me wrong.

> 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.

See above.

> 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?

But 10,000 lines of code will take more time to read than 10 pages of
tight prose and diagrams, even if the code is very well organised and
I just hit the high points.

Where I think the "code as documentation" approach falls down is in
communicating the nasty little details that are buried deep in the
kernel-level code that fopen() relies on. Why, if your approach is
sufficient, does fopen() even need a man page?

A spec can put it right in your face, in bold red type, a tricky part
of the requirements or implementation.

> > 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.

Possible.

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

No, almost certainly not. But if IBM's estimate of one bug per 100
lines of code is correct (was that the number that Brooks used?) is
correct, I claim that my 10 page spec has fewer bugs than your 10,000
lines of code, almost certainly by an order of magnitude and possibly
even two (i.e. my spec has 1-10 bugs, your code has 100 bugs, give or
take the sampling error).

> 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.

Well, my customers are the business people who own the projects, and
ultimately you guys. And while some of you might write AWS code
(thanks!), I doubt the percentage of Amazon customers on this list who
use AWS even reaches double digits, and it will be an order of
magnitude outside this fairly technical list.

> > 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?

Did you see my hard numbers later? I spend 3-5 hours on the initial
spec, plus two hours a week to maintain it for the duration of the
project. On a one-month project, that is 11 hours, or two engineering
days.

> 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.

I claim that specifications save time, and further claim that your
approach, while it seems to work fine for you, would be a huge waste
of time *and* money in the enterprise.

I would love for some XPer to stand up and show me how my reasoning is
flawed, though.

> *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.

I have not made the point that what you do can't work. Please re-read
this thread in its entirety and point out where I have said that.

I use many of the ideas from XP (which is itself a synthesis of a
ideas from a few different sources) in my daily work, including TDD,
refactoring, user stories, etc. I am sceptical about peer programming
being a good idea in the enterprise, and simply dead-set against the
"look Ma, no English specs" approach that you are advocating.

If anything, you are the one refusing to accept any of my ideas due to
your own prejudices.

I am very open-minded. I am willing to give any idea a listen, and
many ideas a whirl. When something doesn't work, I discard it. I am
engaged in heavy 改善 for my development process and environment.

Can you say the same, or are you stuck in an XP-only mindset? (I am
not accusing, I am challenging.)

In any case, I look forward to having this discussion with you in a
public forum, where we can both present our ideas and let the audience
judge which ones will work, each man or woman applying his own context
and mindset.

I have no problems with you, Curt, just keep that in mind and try to
keep your gloves firmly above the belt.

-- 
Cheers,
Josh