Re: [boost] Boost libraries after C++0x acceptance

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-10-10 11:55:04

Richard Hadsell wrote:
> Phil Nash wrote:

> My company (i.e., my boss) is VERY reluctant to rely on third-party
> software, which includes Boost libraries.  If Boost ceased to exist or
> support new compilers, we would be stuck with a major task of
> maintaining code, which we did not develop.  I'm not saying that this
> is likely to happen, and I have managed to convince everyone here that
> Boost is widely accepted and very professionally developed and
> maintained.  However, libraries that are part of a C++ standard give
> us a reliable guarantee that we can use them in code that will work
> on new platforms and compilers with no maintenance needed on our part.

I've seen this phenomenon as well. In my view its very misguided.

suppose my company needs a shared_ptr.  I go to my boss and say
"we need a shared_ptr" and "here is one (boost) which is
a) provided with source code
b) documented
c) rigorously and formally tested.
d) includes all testing infrustructure
e) is compatible with all currently used systems
"
And the boss says - no don't use that - we have no guarentee that it
will be maintained in the future.  Here is what I want you to do:

a) write our own shared_ptr
b) document it - if you have time
c) testing - who has time - just add it to our app and that'll be the test
d) testing infrasture - we can't use third party libraries
e) other systems? - we have our hands full with just our current system.

So you do this.  Now suppose boost disappears and you have to
maintain the shared_ptr yourself.  Which is going to be easier to
maintain in the future?

and what about when you need regex? Are you going to have someone
re-write it from scratch? How much is that going to add to the
delivery date.

The whole issue is really economics of scale.  It means
a) spending time only on those things that are unique to one's application.
b) It means that the work we're doing is more unique and therefore
higher value added to the final product.
c) This implies having a smaller department with a higher percentage
of the employees in the "critical path" of developement.  Since this
is unique and new stuff .
d) This well "seem" more expensive as these employees are likely to be
paid somewhat more than average and they will spend time doing things
like participating in boost, reading journals and books, running small
experiments and going to conferences.  "seem" because the extra
production and lessing of errors isn't measured - only the "cost per
hour of time" is measured and the total time to do a project is considered
fixed independent of the methodology.
d) This leaves a lot less for the "boss" to do.  In fact, you'll need a LOT
less "management" when you have a smaller team.
e) This conflicts with the fundamental metric by which the bosses
performance is measured which is the size of department he can be 
responsable
for without  have a visible screw up.
f) So in order to address this he has to make his team bigger.  He can
encroach on some elses territory - but that usually doesn't work as
he bumps into another manager with the same problem.  He could
try to make products which sell more - But then someone has to come
up with some new idea - which would upset someone.  Even if
someone were to do that, it has to be sold to a bunch of departments
including a sales/support system which has pretty much
lost faith that he can deliver something more or less as promised.
Besides, they're bogged down trying to sell and support something
that's still not working.

The legal department is another log-rolling organization.  Their 
responsability
is to be sure they don't get blamed for anything.  So they always advise
against just about everything regardless of the economic issues involved.

So basically, it's better for all the key decision makers to employ an army
of slaves spending most of their time re-inventing a crappy version of some
existing wheel.  Everyone's busy, work is being done things run smoothly.

OK - I'm exaggerating - but by how much?  There's a reason that large
organization, despite the availability of resources ( infinitely greater 
than
boost's) produce so little new stuff in relation to smaller organizations.

Robert Ramey