Re: [tlug] [OT] Good IT Resume

[Curt Sampson <cjs@example.com>]

On Sun, 29 Jul 2007, Stephen J. Turnbull wrote:

> That's why even though BSD TCP/IP is the generally preferred
> implementation, there is no *reference* implementation.  TCP/IP is a
> separate set of standards, written in *prose*, not code.

That is the case, yes. But that misses the point of what I'm trying to
get at: is it possible to create a specification for TCP/IP that out of
code, or at the very least, replace part of the prose with code?

Look at this:

http://www.research.umbc.edu/~jeehye/cmsc491b/lectures/tcpstate/sld001.htm

Doesn't that seem to you like something that could be expressed as code
and tests (or testable constraints) instead of written prose? Ideally,
that code/spec could be then be executed in TCP implementations, and
not only would we be able to produce from the that sort of picture for
pedagogical purposes, but even animations and so on.

On Sun, 29 Jul 2007, Josh Glover wrote:

> On 29/07/07, Stephen J. Turnbull <stephen@example.com> wrote:
>
> > I think you can be more precise than that.  "It *can't* be done when
> > the code base is large enough to require the team be split into more
> > or less independent groups, some of whose modules must support more
> > than one other teams' modules."...
>
> Yes, I like your definition.
>
> Curt, would you say this is fair, or can you come up with a
> counter-example where XP and PP have scaled to large projects?

For PP, I don't see where there would be any scaling issue. Going from
two pairs of developers to two hundred pairs seems to not to have any
issues that you wouldn't have going from four to four hundred developers
working alone.

By splitting the team into "more or less independent groups," I gather
that you're talking about some sort of different independence than an
XP-style, "Joe and I will work on the frozbat this morning, while you
and Tim work on the whatchuck." Probably what you would do somehow
involves restricting and slowing down communication (c.f. my earlier
message about communication efficiences). I can't tell you from
experience whether or not there are ways to avoid doing that, but I can
tell you that in a project like that, I'd certainly be looking for them.

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