RE: [tlug] [OT] Good IT Resume

[<burlingk@example.com>]

> -----Original Message-----
> From: Curt Sampson
> Sent: Friday, August 03, 2007 5:29 PM

> 
> 
> 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.

I cannot completely agree here.  Idealy, internal
changes should not change the apparent behavior of
a given interface.  Existing interfaces should remain
in place whenever possible to allow the library to 
remain compatible with existing software.

If an interface is that bad, then create a new one 
along side of it.  If the interface is good, but
the underlying code is broken, then fix the code.
Make it more efficient.  Make it work better,
but don't break it if you can avoid doing so. :)

This advise of course is applicable to libraries
that have been under development for a while and 
have wide spread use.  If you are dealing with a
new product, and the only ones that have hold of
it are the "alpha testers" (gods help them), and
the beta testers, then change is expected.  At
that stage, it is acceptable to break anyting and
everything.  :P

Also, if the library is only in use by a tight
knit community of developers who all contribute in
some way to the library and it's developement, then
it is not so hard to send out an email saying "Hey,
we might be breaking this.  This is how we plan to
do it, and why...."

:-)

> 
> 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."
> 

If the interface is wrong, create a new interface.  Use
different functions to point to the interface, so that the
old interface still exists.  Often when a company is in a
position though, where someone in the "chain of command" so 
to speak actually has enough of a clue to know what an
interface is (or even the difference between a chunk of code
and your lunch order), then you aren't dealing with the
average scenerio.  :-)  Generally, when you are expected
a fight to keep the same client, it is because you are
dealing with a corporate environment. 

Personally, if I had the skill to do so, I would love
to work in an environment where my employer would allow
me to pick and choose the tools of my trade.  :-)
(I am slowly but surely working on the skill thing).
Maybe someday I will be able to afford my own business. ^_^



> 
> 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.
> 

THAT is where the biggest problems are.  Libraries update,
but other things do not.  ^^;;  Then one day a user needs
to upgrade the library to the newest version in order to
use their neat new music player, or the newest version of
their text editor, only to discover that it breaks their
video player, and the video player doesn't have a version
for the updated library (or for that matter any of the
last twelve versions of the libary). :P

THAT cannot be blamed completely on the library developers.
It is still ultimately their decision to drop support for
an API call (so they are partly to blame), but it is also
an application's dev team's choise of whether or not to
update their code to use a new library (their share of the
blame).  Of course we can't forget the end user who will
occasionaly go out and install a neet looking app that has
not been updated in over six years. ^_^  See, everyone is
to blame! heheheh ^_^


>
> > 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.
> 

Modularity and backwards compatability are not always
the same, nor are they always different.  They are two
separate decisions that have to be made by each
developer involved.  You can maintain neither, both, or
pick and choose. :)