Re: [tlug] [OT] Good IT Resume

[Curt Sampson <cjs@example.com>]

On Fri, 3 Aug 2007, Josh Glover wrote:

> Well, this is another very good reason why people should not break
> backwards compatibility unless absolutely necessary.

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

Not breaking backward compatability causes definite harm if the library
is not already perfect.

Mostly, folks say, "the interface is incorrect, the design of the thing
is wrong, there are bugs that are hard to fix, etc., etc., but we'll
spend money every single day on these problems in order to keep backward
compatability."

That's can be a good business decision if you let yourself slide into a
hole where you can't easily change the clients. But keep in mind, you
put yourself in that hole (knowingly or unknowingly); you didn't have to
be there.

> No, it is the Only Way, unless, like Curt, you own a company that is
> small enough that you can treat the code as one block.

I don't treat the code as one block. I treat it as a dozen or more
separate applications, each using whatever version of the library and
API it happens to be using. Sometimes, if I wait too long to upgrade
an app, it gets a bit painful. (I define "painful" as "more than ten
minutes.") But that's still much better than having a sucky library or
framework because I won't change a broken API, and I save a lot more
time in the long run because of how fast it's improving.

> But even then, if you want to use other code, you have to learn to
> play with modular code.

Side note, in case there's any misinterpretation here, all of Starling's
code is extremely modular. I'm discussing backward compatability,
changing APIs and agility here.

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