Re: [tlug] [OT] Good IT Resume

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

On 26/07/07, Darren Cook <darren@example.com> wrote:

> Agile/XP, as I understand, still uses specs, but the scope of each is
> much smaller. You have a lot more iterations. And because each iteration
> costs less you can afford to be short and imprecise; you don't have to
> spend a week hammering out a highly detailed document to make sure that
> there will be no misunderstandings a month or two later when you deliver
> something.

My specifications process works exactly as you have just detailed,
with the only difference being that the output of the process is a
document.

> Instead you spend 10 minutes chatting, pointing at the
> screen, then maybe write a short email to summarize the feature request.
> Then spend the rest of the day working on it. Get approval at the end of
> the day. Next day repeat for the next feature request.

For me, the specifications process costs about 3-5 hours up front,
depending on the size and scope of the project, and then about two
hours every week that I spend working on the project to keep the spec
up to date. Considering that I have five engineering hours a day, that
means that 28% of my time goes to specs the first week of the project,
then 8% for subsequent weeks.

And yes, I really do measure things like this. Cf. Emerson's talk on
the Black Art of Estimation, estimates are no good unless you track
actual time and adjust your estimates next time.

> It works well for some kinds of projects, and some people. I'm not sure
> programmer excellence is a factor. Company size is more of a factor:
> bigger companies tend to want more up-front paperwork.

Bigger companies tend to require more up-front paperwork, for the
simple fact that the next time the project gets touched, the personnel
could be completely different.

In big companies, your code tends to have a lot of secondary users,
meaning that other people's code depends on your code. I write
frameworks; could you imagine the chaos if it did not have a spec and
an API document at the end of a framework project? I would quite
frankly deserve to lose my job behind that kind of unprofessionalism.

No formal specs works for Curt because his shop is small and the
quality of the engineers he hires is high. In his shop, he probably
keeps the spec of each project they work on in his head, and that is
fine for him.

But it does not scale.

I work for a company that employs something like 4000 software
engineers. Do you really think even senior architects at Amazon have
more than a cursory understanding of even 10% of our codebase? So how
are they able to direct the architecture of the overall website
platform, or AWS, or MTurk? By reading specifications that flow
upwards from project teams.

I will sanitise a spec that I wrote for a recent project and run it by
my boss; if he approves, I will post it here so that my money is
firmly where my mouth is.

-- 
Cheers,
Josh