[not entirely OT] proper terms for grades of freedom

[Oleg Goldshmidt]

Oron Peled <oron at actcom.co.il> writes:

> Simplified explanation: When software teams are pressured by management
> to produce results at impossible deadlines, without taking maintenance
> into consideration (clients pays only for features, or fixing immediate
> critical bugs) -- than over sufficient time and project complexity the
> code quality is almost bound to be bad.

Hear, hear, but I find that the most common (and to me, the most
baffling) reason given for the pressure is the mythical "time to
market"...

I cringe each time I hear "we can't afford to do it right" argument
(most frequently from otherwise very competent senior technical
managers, not marketeers). My normal retort ("No, we can't afford to
do it WRONG!") rarely convinces anyone, even if I show that doing it
right will not require more time or resources even in the short term.

> There is a lot of FOSS crappy code as well. However, in mature FOSS
> projects, there is some minimal quality required of *new* code entering
> the project. Since this "bar" is set by programmers (usually from
> different companies) it is not lowered so easily by marketing people
> or managers of a specific company. Even if they badly want a new
> feature *now*.

I believe there is yet another factor that makes proprietary code
crappier on average than *mature* open source. It is indeed related to
the "quality bar" that Oron mentioned. However, it is not 100%
one-sided "programmers vs. marketoids" thing (although
marketoids/managers are often near-sighted indeed).

The key point is that good FOSS projects are usually run by developers
who have "rosh gadol", who see the big picture, who are capable of
making decisions for the project rather than specific engineering
decisions for a particular "function point".

It struck me more than once during my career how many developers there
are in the corporate world who, while not completely devoid of
aptitude, exhibit rather astonishing narrow-mindedness and adopt a
"let me quickly fix the next bug assigned to me and leave me alone"
attitude. There are lots of them in private enterprise (and, I guess,
in government shops, too), because there is a space for them. I'd
venture an opinion that they are convenient both to their insecure
managers and to their not very professional colleagues, they are not
politically dangerous, they don't rock the boat, they are not very
demanding, they don't generate that most dreaded thing of all
- change. And they tend to give lower effort estimates than really
good engineers who see a bigger picture and worry about design,
maintenance, flexibility for future modifications, and other
inconveniences. Management and salespeople love low effort estimates
and think that spaghetti is a kind of pasta. Managers also like the
fact that you typically need more "roshim ktanim" than "gdolim" for
the same tasks - meaning a larger "empire", headcount, budget, etc.

[Mind you, I've seen managers, product people, customer support
personnel, and even marketeers (not *all* of them are dumb) become
very frustrated by the "rosh katan" attitude of developers.]

Such narrow-minded programmers are not very likely to start or lead an
open source project. If they stumble into such position by some quirk
of fate chances are the project will go under for reasons discovered
by one C. Darwin long before computers came about. FOSS projects that
survive to maturity are simply likelier to be run by folks whose
brains operate beyond specific knowledge of the syntax of one
programming language and the APIs of two libraries. The likelihood is
guaranteed by natural selection.

A final world of caution: while survival of the fittest is a plausible
explanation for higher quality one should not forget the old
observation that Nature (like many volunteer FOSS projects) does not
have schedule or budget restrictions...

-- 
Oleg Goldshmidt | pub at goldshmidt.org