Re: [tlug] [OT] Good IT Resume

[Curt Sampson <cjs@example.com>]

On Tue, 24 Jul 2007, Josh Glover wrote:

> I can see now why we are on the opposite side of so many software
> engineering issues. I am firmly in the Joel Camp on nearly everything. :)

Which may mean you agree with me in the end, for all I know. There
was a big brou-ha-ha a while back in which Joel inveighed against XP,
and used Project Aardvark as an example of how you should always do
specifications, and it turned out that the "specification" was something
I'd be happy to use as XP training material for the "don't do big
specifications" part of the course.

"I'm agile but won't admit it," maybe.

> I think in your case, you have a special situation: you are running
> your own company, full of like-minded people, and you have the final
> say over what happens.

Now, yes. But this was not developed in my company, this was developed
through three or four other companies, and worked through with a fair
number of programmers. And I've coached this since then in various other
companies as well.

I've certainly had failures teaching this, but looking back, I can
identify enough colossal errors on my part that I'd be pretty hesitant
to lay the blame on a process that's made me and others three or four
times as productive and happy as I/we used to be.

> Most of what you recommend is simply not applicable at a big company;
> I might get fired outright for practising what you preach, and
> rightfully so.

Sure. But "righfully" in the sense that you're in a social situation
where producing the best possible system is not the goal. The
stockholders are not interested in how good your product is; they're
intersted in how much money they make. A profitable failure is better
than a success that makes little money.

> I really think the issue comes down to what Steve points out: the
> XP-centric approach you use really does not scale to a) large teams...

Possibly not. And I'm not claiming it does scale to large teams. But do
we care? You have to admit, even taking into account the best large-team
successes (the IBM 360, the 747), most of the Good Stuff comes from
small teams. And the large team successes are not at all reproducible:
in 37 years, we have yet to come up with a better overall commercial
airliner than the 747.

If you want a real success, use a small team, not a large one.

> or b) programmers who are not in the top %1.

That I'm also going to disagree with. I've worked with a lot of junior
developers, and in my experience, they excel when you bring them "in to
the fold," as it were, rather than relegate them to "program to this
specification."

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