Re: [tlug] [OT] Good IT Resume

[Darren Cook <darren@example.com>]

>  > Well, this is another very good reason why people should not break
>  > backwards compatibility unless absolutely necessary.
> 
> Curt's point and Ken's experience is that if the projects are as
> independent as Darren's words suggest (to me, at any rate, I don't
> know what he intended) breaking compatibility is inevitable.
> ...
> Note that the XP/agile/small is beautiful proponent was the one who
> reacted most quickly and violently to Darren's statement, while Josh,
> the Prince of Process (Take that, you cur!  DOCTOR, indeed) is
> defending an advocate of extreme modularization.

Yes, I thought that was interesting.

The key of my proposal was to take one big codebase, split into
sub-projects along natural lines, and for each sub-project make a public
API that is as small as feasible. Each sub-project could then be run
more efficiently with its own smaller number of programmers, free to
modify all the non-public functions.

Naturally they are not allowed to refactor the public API; at least not
without permission of all the other projects in your company that depend
on it. You have lots of unit tests in place on the public API functions
to prevent breaking backwards compatibility.

Stephen also wrote, in reply to Curt:

> > Breaking backward compatability in a library causes little harm if the
> > users of the library are agile.
> 
> And singular.

This is basically the case when users of the library are internal to the
company.

Darren