Motivation of software professionals

[James Kanze]

Nonsense. Free software has a much higher rate of adoption
of best practices for high quality than for-pay software
does.
You say so, too. It's the "logically" with which I take
issue. That free software uses the best techniques and has
the highest quality in the marketplace is entirely logical,
in addition to being an observed fact. You just have to
avoid false assumptions and fallacies in reasoning.

[/QUOTE]

Not sure what you mean. There are no such logical binary
connection. Opposite is as easy to observe.

Just download few C++ code-bases at random from places like
sourceforge.net and review them.

I'm not sure that that's significant. It's less expensive to
publish free software, so you get a lot of idiots doing it. But
these are mostly products that no one is interested in. And
there are actually quite a few start-up companies which do
exactly the same thing. The difference is that the start-up
company will go out of business, and disappear, where as the
code on SourceForge just sits there.

If you're talking about successful projects, there are some good
free ones.

One produced by using good techniques is really hard to find
there. Most code there has quality so low that it would be
unthinkable in professional software house to pass QA peer
review with it.

I've had the chance of working mostly in well run shops, but
I've seen places where there was no peer review. Not all
commercial shops are better.

It is easy to logically explain since most of it is hobby of
non-professionals who find software development amusing or
professionals of other language who learn C++ as hobby.

Results are slightly better with larger and more popular open
source products but that is often thanks to huge tester and
developer base and not good techniques used.

At least some of the larger open source projects have a steering
committee, and do practice at least some sort of code review and
regression testing.

In best shape are open source projects that are popular and
where commercial companies are actively participating since
they need these for building or supporting their commercial
products. Again it is easy to see how the companies are
actually enforcing the techniques and quality there and it is
likely that the companies use even higher standards in-house.

Worst what i have seen is the code written by in-house
software department of some smaller non-software companies but
that is again easy to explain by workers of that department
obfuscating their work to gain job security.

So all things have logical explanations and there are no silly
binary connections like free = quality and commercial = lack
of quality.

Quality is largely determined by the development process. Some
of the better processes probably can't be applied to a free
project, at least not easily. But a lot of commercial projects
aren't applying even a minimum, and some of the better freeware
projects have applied some of the easier and more obvious
techniques. In the end, if you want quality, you have to
consider the process used to develop the software, independently
of the costs.

 

[James Kanze]

They might be hard to apply, but consider that a great deal of
free software is written without idiots saying "you need to
get this done sooner so we can book revenue this quarter to
please shareholders".

If your point is that some (most?) commercial vendors don't have
a good development process, I already pointed that out.

It's also often written by particularly good developers, who
care about their code.

That I don't believe. I've seen a lot of particularly good
developers in industry as well. People who care about their
code---in fact, one of the most important things in creating a
good process is to get people to care about their code.

It is also probably an influence that free software writers
expect the code itself to get feedback, not just the behavior
of the application. I have submitted bug reports about
poorly-expressed code, not just about code which didn't work.

In a well run development process, such feedback is guaranteed,
not just "expected". That's what code reviews are for.

Again, I don't think there's actually any force driving that.
The benefits of well-written software are significant enough
that it is likely worth it to some people to improve software
they have access to, and if it's worth it to them to do that,
it costs them virtually nothing to release the improvements.

Free software often ends up with the best efforts of hundreds
of skilled programmers, with active filtering in place to keep
badly-written code from sneaking in.

I'm far from sure about the "often", and I have serious doubts
about "hundreds"---you don't want hundreds of cooks spoiling the
broth---but that's more or less the case for the best run
freeware projects. Which is no different from the best run
commercial organizations, with the difference that the
commercial organization has more power to enforce the rules it
sets.

If you are implying that CC is actually usable to you, that
marks a first in my experience. No one else I've known has
ever found it preferable to any of the open source tools, of
which git is probably currently the most elegant.

ClearCase is by far the best version management system for
large, well run projects. It's a bit overkill for smaller
things, and it causes no end of problems if the project isn't
correctly managed (but what doesn't), but for any project over
about five or six people, I'd rather use ClearCase than anything
else.

Another issue is that, if you give away open source software,
people can modify it. If you modify my code, and your
modification is not itself buggy, and my code is not itself
buggy, but your modification causes some part of my code not
to work as expected, whose fault is that? This kind of thing
is a lot more complicated with code than it is with physical
objects. You don't have a million people using a bridge, and
a couple hundred thousand of them are using the bridge
recompiled for sports cars, and another couple hundred
thousand are running it with a third-party tollbooth
extension.

That is, of course, a weakness of free software. A company
using it, however, should be able to manage this (although I
once worked for a company where one employee would slip
modifications into the g++ we were trying to use for production
code, without telling anyone).

 

[James Kanze]

[I really shouldn't have said "most" in the above. "Some"
would be more appropriate, because there are a lot of
techniques which can be applied to free development.]

I'm not sure what you are referring to, but one thing we
agree is important to software quality is code reviewing.
That can be done in a small company and I'm sometimes
given feedback on code in newsgroups and email.

To be really effective, design and code review requires a
physical meeting. Depending on the organization of the project,
such physical meetings are more or less difficult.

Code review is *not* just some other programmer happening to
read your code by chance, and making some random comments on
it. Code review involves discussion. Discussion works best
face to face. (I've often wondered if you couldn't get similar
results using teleconferencing and emacs's make-frame-on-display
function, so that people at the remote site can edit with you.
But I've never seen it even tried. And I note that where I
work, we develop at two main sites, one in the US, and one in
London, we make extensive use of teleconferencing, and the
company still spends a fortune sending people from one site to
the other, because even teleconferencing isn't as good as face
to face.)

Maybe now that Sun CC and VC++ are free they'll improve.

I doubt it. Making something free doesn't change your
development process. (On the other hand, if it increases the
number of users, and thus your user feedback, it may help. But
I don't think any quality problems with VC++ can be attributed
to a lack of users.)

I'm not sure about Sun CC, but guess that it is free with
Open Solaris. Still I'm not comfortable with g++'s foundation.
I would like to think that VC++, written mostly in C++, is at
least able to produce a draw when up against g++.

There are a lot of factors which affect quality, but the basic
development process is by far the most important one. And from
what I've seen, I'd guess that Microsoft doesn't have a
particularly good process. Note that it's a lot easier to have
a good process when relatively few people are involved. Which
works against Microsoft, and also to a degree against g++. And
may contribute to explaining why the EDG front-end is so good
(along with the fact that it's probably easier to find four
exceptional people than to find 400).

[...]

That may be a reason why an on line approach makes sense.
Since you haven't shipped out instances of the program,
just make sure the instances that exist on your servers
are corrected. The other way, a court in a distant country
might hold you liable if some customers didn't receive a
message that they should update their copy.

Who knows what a court in a distant country may decide. (Note
that Microsoft now uses the push model for patches---by default,
automatic upgrading is activated, and you get all of the latest
patches for Windows, whether you asked for them or not.)

 

[James Kanze]

James Kanze wrote: [...]

The "standard" life of a railway locomotive is thirty or fourty
years. Some of the Paris suburbain trainsets go back to the
early 1970's, or earlier, and they're still running.

Do you happen to know if they've undergone any engineering
changes over those 40 years for safety or performance
enhancements?

Engineering changes, I don't know; I think in many cases, no.
(The "petit gris" commuter equipment in the Paris area certainly
hasn't changed much since its introduction.) But they are
maintained, with regular check-ups, replacement of worn parts,
etc., and if there were a safety defect, it would be corrected.

With worn/damaged parts replacement how much of the original
equipment remains? Wheel sets, motors, controls, seats,
doors, couplers, windshields, etc. all get inspected and
replaced on schedule.

Certainly. Hardware wears out. Even on your car, you'll
replace the brake pads from time to time (I hope). In the case
of locomotives, a lot more gets changed. But for the most part,
it's a case of replacing a standard component with a new, but
otherwise identical, component.

Not that that was my point. My point was that any embedded
software they're using was written before 1975 (more or
less---in the case of the "petit gris", before 1965, when the
first deliveries took place).

(The "petit gris" are the Z 5300 "automotrices" used by the
French railways in suburban service. They're very well known to
anyone commuting in the Paris area. I'm not aware of any
information about them in English, but
http://fr.wikipedia.org/wiki/Z_5300 has some information in
French, for those who can read French and are interested. The
main point is that they were put into service starting in 1965,
and are still in service, without any real changes, today.)

Not all locomotives last 40 years.

Design flaws can contribute to a shorter life. For example the
Erie
Triplex.http://www.dself.dsl.pipex.com/MUSEUM/LOCOLOCO/triplex/triplex.htm

Certainly, and others might last longer. (But somehow, I doubt
that the Erie Triplex had any embedded software, that could have
failed if the locomotive had still been in use in the year
2000.)

Although design flaws played a part in the death of the Jawn Henry, I've
heard that N&W's business was undergoing changes and undercut the
companies desire to invest in coal fired power.http://www.dself.dsl.pipex.com/MUSEUM/LOCOLOCO/nwturbine/nflkturb.htm

To continue with our locomotives, the replacement of coal
fired steam by diesel and electric (No, no, not this
one:http://www.dself.dsl.pipex.com/MUSEUM/LOCOLOCO/swisselec/swisselc.htm;))
power was largely driven by maintenance cost, the sort that
replaces the lubricating oil, not the kind that replaces
faulty brake systems, although this played a role too. It's
nice to be able to buy parts OTS if you need them rather than
have a huge work force ready to make parts.

Yes. But that's not really the issue here. I'm not sure when
the Swiss started using regenerative braking on the Gotthard
line, but when they did, they obviously had to retrofit a number
of locomotives in order for it to work. But that doesn't mean
that the original locomotives weren't designed with the idea
that they'd be used 40 years; it doesn't necessarily mean that
all of the programs embedded in them were replaced (although I
think that a move to regenerative braking might affect most of
them).

 

[Arved Sandstrom]

[ SNIP ]

I think you'd find that if there was much less free stuff
available that we'd have a _different_ economic model, not
necessarily a _worse_ one.
There used to be a lot less free stuff available, and it was
worse. (It doesn't make sense to me, either, but those are
the facts.)
I look at warranties differently than you do. To me a
warranty means that I used proper development practices, I
can make informed statements that the published software is
actually fit for a stated use, and that I care enough about
the program to offer some support.
Clearly. The problem is that most commercial firms don't do
that.

Right, and that's because usually the _only_ difference
between free and commercial software right now is the price.
Paid-for software doesn't come with any more guarantees or
support than the free stuff does; in most cases you actually
have to pay extra for support packages.

In effect the commercial software is also crappy because we do
not hold it to a higher standard. I believe that a
well-thought-out system of software certifications and hence
guarantees/warranties will lead to a saner market where the
quality of a product is generally reflected in its cost.

I think you're maybe confusing cause and means. I'm not
convinced that certification of professionals is necessary; I am
convinced that some "implicit" warrenties are necessary, and
that if an editor trashes my hard disk, the vendor of the editor
should be legally responsible.

Certification, in practice, only helps if 1) the vendor is
required to use only certified people in the development
process, 2) the certification really does verify ability in some
way, and 3) the vendor allows the certified people to do things
in the way they know is correct. In practice, I don't think 1
and 3 are likely, and in practice, there are plenty of capable
people around today, without certification, who would do a very
good job if the vendors would ask them to do it, and structure
their organization so they can. I've worked in places where
we've produced code with quality guarantees, and where we've
produced we've produced code which met those guarantees. And
the people there weren't any more (or less) qualified than the
people I've seen elsewhere. The problem isn't the competence of
the practitioners (which is the problem certification
addresses), but the organizations in which they work.

This is all true, and IMO you can only make all of that happen if we
have true professionals. There is however more needed in order to tie it
all together, and you've touched upon it. For certain types of work -
taxpayer-funded for starters - it would not be permitted to use
non-professionals. Given that, and the fact that professionals have a
duty to do proper work, no PM would be able to legally go against the
advice of his developers when the latter deliver it as a professional
recommendation.

But I agree with you, I don't think 1 or 3 are likely. Hell, I don't
think 2 is likely either.

 

[Martin Gregorie]

Do you happen to know if they've undergone any engineering changes over
those 40 years for safety or performance enhancements?

Some have gone on a *lot* longer: the youngest engine on the Darjeeling
Railway was built in 1925 and I remember seeing a brass plate on one
saying that it was built in Glasgow in 1904. More recently, one was
converted from coal to oil and fitted with a diesel generator to run the
new electric water feed system and a diesel compressor for braking.
Details are here:
http://en.wikipedia.org/wiki/Darjeeling_Himalayan_Railway

 

[Martin Gregorie]

James Kanze wrote:
On 12 Feb, 22:37, Arved Sandstrom <[email protected]> wrote:

[ SNIP ]

I think you'd find that if there was much less free stuff available
that we'd have a _different_ economic model, not necessarily a
_worse_ one.

There used to be a lot less free stuff available, and it was worse.
(It doesn't make sense to me, either, but those are the facts.)

I look at warranties differently than you do. To me a warranty means
that I used proper development practices, I can make informed
statements that the published software is actually fit for a stated
use, and that I care enough about the program to offer some support.

Clearly. The problem is that most commercial firms don't do that.

Right, and that's because usually the _only_ difference between free
and commercial software right now is the price. Paid-for software
doesn't come with any more guarantees or support than the free stuff
does; in most cases you actually have to pay extra for support
packages.

In effect the commercial software is also crappy because we do not
hold it to a higher standard. I believe that a well-thought-out system
of software certifications and hence guarantees/warranties will lead
to a saner market where the quality of a product is generally
reflected in its cost.

I think you're maybe confusing cause and means. I'm not convinced that
certification of professionals is necessary; I am convinced that some
"implicit" warrenties are necessary, and that if an editor trashes my
hard disk, the vendor of the editor should be legally responsible.

Certification, in practice, only helps if 1) the vendor is required to
use only certified people in the development process, 2) the
certification really does verify ability in some way, and 3) the vendor
allows the certified people to do things in the way they know is
correct. In practice, I don't think 1 and 3 are likely, and in
practice, there are plenty of capable people around today, without
certification, who would do a very good job if the vendors would ask
them to do it, and structure their organization so they can. I've
worked in places where we've produced code with quality guarantees, and
where we've produced we've produced code which met those guarantees.
And the people there weren't any more (or less) qualified than the
people I've seen elsewhere. The problem isn't the competence of the
practitioners (which is the problem certification addresses), but the
organizations in which they work.

This is all true, and IMO you can only make all of that happen if we
have true professionals. There is however more needed in order to tie it
all together, and you've touched upon it. For certain types of work -
taxpayer-funded for starters - it would not be permitted to use
non-professionals. Given that, and the fact that professionals have a
duty to do proper work, no PM would be able to legally go against the
advice of his developers when the latter deliver it as a professional
recommendation.

That would never happen in the British civil service: the higher
management grades would feel threatened by such an arrangement. They'd
use sabotage and play politics until the idea was scrapped. I bet the
same would happen in the US Govt too.

 

[Arved Sandstrom]

On Sun, 14 Feb 2010 14:14:26 +0000, Arved Sandstrom wrote:

[ SNIP ]

That would never happen in the British civil service: the higher
management grades would feel threatened by such an arrangement. They'd
use sabotage and play politics until the idea was scrapped. I bet the
same would happen in the US Govt too.

I don't exactly see it happening at the federal or provincial or
municipal levels in Canada either. Not any time soon. Which is ironic,
because this would simplify the lives of PMs and higher-level managers.

AHS

 

[Seebs]

Really. I've not seen any free software which adopted all of
the best practices.

Bespoke software may. But go to a store that sells discs in boxes,
and tell me with a straight face that any of those boxes contain software
developed through a development operation which adpoted all of the best
practices.

In my experience, some of the best
practices require physical presense, with all of the developers
having offices in the same building. (The experiments I've seen
replacing this with email and chat haven't turned out all that
well.) This is far more difficult for a free project to achieve
than for a commercial one.

True. That said, I've been on distributed teams pretty much exclusively
for the last couple of decades, and I think they certainly *can* work. It
depends a lot on building a culture that's suited to it, and probably also
on having a few aspies involved. (It is nearly always the case that I
am less efficient in face-to-face meetings than I am in pure-text chat.)

First, free software doesn't have the highest quality. When
quality is really, really important (in critical systems), you
won't see any free software.

I'm not totally sure of this. Not *much* free software, probably.
It'd be interesting to see, though. Last I heard, there's no open
source pacemakers, but there are pacemaker programmers which are
built on open source platforms, because that's enough less critical.
(This is third-hand, so no citations.)

ClearCase uses a different model than any of the other version
management tools I've used. In particular, the model is
designed for large projects in a well run shop---if your
organization isn't up to par, or if your projects are basically
small (just a couple of people, say up to five), ClearCase is
overkill, and probably not appropriate. If you're managing a
project with five or six teams of four or five people each, each
one working on different (but dependent) parts of the project,
and you're managing things correctly, the ClearCase model beats
the others hands down.

Hmm. I'm not familiar with its model, but we've used git in that
environment and loved it. That said, we can't see the model for
the interface, which is pretty weak.

Did you actually try using any free software back in the early
1990's?

I did.

NetBSD was for the most part reliable and bulletproof during that time;
it ran rings around several commercial Unixes. I had no interest in g++;
so far as I could tell, at that time, "a C++ compiler" was intrinsically
unusable. But gcc was stable enough to build systems that worked reliably,
and the BSD kernel and userspace were pretty livable.

Neither Linux nor g++ were even usable, and emacs (by
far the highest quality free software), it was touch and go, and
depended on the version. Back then, the free software community
was very much a lot of hackers, doing whatever they felt like,
with no control. Whereas all of the successful free software
projects today have some sort of central management, ensuring
certain minimum standards.

I have no idea what you're talking about. I cannot point to any point
in the history of my exposure to free software (which predates the 1990s)
at which any major project had no central management. Linux was pretty
flaky early on, but then, in the early 1990s, all it had to do was be
more stable than Windows 3.1, which was not a high bar to reach for.

-s

 

[Seebs]

That I don't believe. I've seen a lot of particularly good
developers in industry as well. People who care about their
code---in fact, one of the most important things in creating a
good process is to get people to care about their code.

I don't see how that argues against free software being written, in
some or many cases, by "particularly good developers, who care about
their code."

In a well run development process, such feedback is guaranteed,
not just "expected". That's what code reviews are for.

True. But of commercial places I've worked, only a few have been anywhere
near as active in code reviews as the free software projects I've worked with.
I have not yet seen a free software project which wouldn't reject code purely
on the basis that it had poor style or didn't match coding standards. I have
seen several commercial projects which didn't. So while good commercial
places may be that good, I've seen nothing to suggest that free software
places aren't usually that good.

I'm far from sure about the "often", and I have serious doubts
about "hundreds"---you don't want hundreds of cooks spoiling the
broth---but that's more or less the case for the best run
freeware projects. Which is no different from the best run
commercial organizations, with the difference that the
commercial organization has more power to enforce the rules it
sets.

And more incentive to cheat around the edges. This is the essential
flaw of corporations.

ClearCase is by far the best version management system for
large, well run projects. It's a bit overkill for smaller
things, and it causes no end of problems if the project isn't
correctly managed (but what doesn't), but for any project over
about five or six people, I'd rather use ClearCase than anything
else.

Fascinating. Again, not what I've heard -- but to be fair, I've had
no call to use it.

That is, of course, a weakness of free software.

I don't think it's a weakness in free software; I think it's a weakness in
a liability model. The ability to modify code when it doesn't quite suit
is a huge advantage. If we were dependent on reporting bugs to vendors and
waiting for their fixes for everything we use, it would be a disaster.
We put up with it, for one hunk of code, because the cost of maintaining local
expertise would be prohibitive. Apart from that, no.

-s

 

[Seebs]

To be really effective, design and code review requires a
physical meeting. Depending on the organization of the project,
such physical meetings are more or less difficult.
Nonsense.

Code review is *not* just some other programmer happening to
read your code by chance, and making some random comments on
it. Code review involves discussion. Discussion works best
face to face.

IMHO, this is not generally true. Of course, I'm autistic, so I'd naturally
think that.

But I've been watching a lot of code reviews (our review process has named
reviewers, but also has reviews floating about on a list in case anyone
else sees something of interest, which occasionally catches stuff). And what
I've seen is that a whole lot of review depends on being able to spend an
hour or two studying something, or possibly longer, and write detailed
analysis -- and that kind of thing is HEAVILY discouraged for most people
by a face-to-face meeting, because they can't handle dead air.

Certainly, discussion is essential to an effective review. But discussion
without the benefit of the ability to spend substantial time structuring and
organizing your thoughts will feel more effective but actually be less
effective, because you're substituting primate instincts for reasoned
analysis.

I really don't think that one can be beaten. If what you need for a code
review is for someone to spend hours (or possibly days) studying some code
and writing up comments, then trying to do it in a face-to-face meeting would
be crippling. Once you've got the comments, you could probably do them
face-to-face, but again, that denies you the time to think over what you've
been told, check it carefully, and so on. You want a medium where words sit
there untouched by the vagaries of memory so you can go back over them.

But!

You do need people who are willing and able to have real discussions via text
media. That's a learned skill, and not everyone's learned it.

It is not universally true that discussion "works best face to face".
Certainly, there are kinds of discussions which benefit heavily from
face-to-face exposure. There are other kinds which are harmed greatly by
it. Perhaps most importantly, many of the kinds which are harmed greatly
by it *FEEL* much better face-to-face, even though they're actually working
less well.

The curse of being made out of meat is that your body and brain lie to
you. Knowing about this is the first step to overcoming the harmful side
effects.

-s

 

[Martin Gregorie]

I have no idea what you're talking about. I cannot point to any point
in the history of my exposure to free software (which predates the
1990s) at which any major project had no central management. Linux was
pretty flaky early on, but then, in the early 1990s, all it had to do
was be more stable than Windows 3.1, which was not a high bar to reach
for.

About the best free software I remember from that era was Kermit. It
worked and worked well and had ports to a large range of OSen and
hardware of widely varying sizes: I first used it on a 48 KB 6809 running
Flex-09 and still use it under Linux. It had an open development model
though it was managed within a university department, so the project
owners had pretty good control over it.

 

[Nick Keighley]

I know of system's that still poke data down 9600b lines.

The "standard" life of a railway locomotive is thirty or fourty
years.  Some of the Paris suburbain trainsets go back to the
early 1970's, or earlier, and they're still running.


Have you been to a bank lately, and seen what the clerk uses to
ask about your account?  In more than a few, what you'll see on
his PC is a 3270 emulator.  Again, a technology which goes back
to the late 1960's/early 1970's.

travel agencies seem to run some pretty old stuff

It depends on what you're writing, but planned obsolescence
isn't the rule everywhere.

I believe the UK's National Grid (the high voltage country-wide power
distribution system) wanted one-for-one replacements for very old
electonic componants. What had been a rats nest of TTL (or maybe
something older) was replaced with a board containing only a few more
modern components (maybe one). But the new board had to have the same
form factor, electrical power requirements etc. This becasue they
didn't want to actually replace the computers they were part of.

I know of software that runs on an emulated VAX.

Sometimes software far out lives its hardware.

 

[Mr. Arnold]

Andy Champ wrote:

<snipped>

What are you talking about? What is your point with this post, other
than some kind of rant?

 

[Brian]

[I really shouldn't have said "most" in the above. "Some"
would be more appropriate, because there are a lot of
techniques which can be applied to free development.]

I'm not sure what you are referring to, but one thing we
agree is important to software quality is code reviewing.
That can be done in a small company and I'm sometimes
given feedback on code in newsgroups and email.

To be really effective, design and code review requires a
physical meeting. Depending on the organization of the project,
such physical meetings are more or less difficult.

Code review is *not* just some other programmer happening to
read your code by chance, and making some random comments on
it. Code review involves discussion. Discussion works best
face to face. (I've often wondered if you couldn't get similar
results using teleconferencing and emacs's make-frame-on-display
function, so that people at the remote site can edit with you.
But I've never seen it even tried. And I note that where I
work, we develop at two main sites, one in the US, and one in
London, we make extensive use of teleconferencing, and the
company still spends a fortune sending people from one site to
the other, because even teleconferencing isn't as good as face
to face.)

It hadn't really dawned on me that my approach might be
thought of like that. The rabbis teach that G-d controls
everything; there's no such thing as chance or coincidence.
The Bible says, "And we know that all things work together
for good to them that love G-d, to them who are the called
according to His purpose." Romans 8:28. I get a lot of
intelligent and useful discussion on gamedev.net, here and
on Boost. It's up to me though to sift through it and
decide how to use the feedback. I've incorporated at
least three suggestions mentioned on gamedev and quite a
few more from here. The latest gammedev suggestion was to
use variable-length integers in message headers -- say for
message lengths. I rejected that though as a redundant
step since I'm using bzip for compression of data. I
thought for awhile that was the end of that, but then
remembered that there's a piece of data that wasn't
compressed -- the length of the compressed data that is
sent just ahead of the compressed data. So now, when
someone uses compression, the length of the compressed
data is generally also compressed with the following:
(I say generally because it depends on the length of
data.)


uint8_t
CalculateIntMarshallingSize(uint32_t val)
{
if (val < 128) { // 2**7
return 1;
} else {
if (val < 16384) { // 2**14
return 2;
} else {
if (val < 2097152) {
return 3;
} else {
if (val < 268435456) {
return 4;
} else {
return 5;
}
}
}
}
}


// Encodes integer into variable-length format.
void
encode(uint32_t N, unsigned char* addr)
{
while (true) {
uint8_t abyte = N & 127;
N >>= 7;
if (0 == N) {
*addr = abyte;
break;
}
abyte |= 128;
*addr = abyte;
++addr;
N -= 1;
}
}


void
Flush()
{
uint8_t maxBytes =
CalculateIntMarshallingSize(compressedBufsize_);
uint32_t writabledstlen = compressedBufsize_ - maxBytes;
int bzrc = BZ2_bzBuffToBuffCompress(reinterpret_cast<char*>
(compressedBuf_ + maxBytes),
&writabledstlen,
reinterpret_cast<char*>
(buf_), index_,
7, 0, 0);
if (BZ_OK != bzrc) {
throw failure("Buffer::Flush -- bzBuffToBuffCompress failed ");
}

uint8_t actualBytes = CalculateIntMarshallingSize(writabledstlen);

encode(writabledstlen, compressedBuf_ + (maxBytes - actualBytes));
PersistentWrite(sock_, compressedBuf_ + (maxBytes - actualBytes),
actualBytes + writabledstlen);
index_ = 0;
}


Those functions are from this file --
http://webEbenezer.net/misc/SendCompressedBuffer.hh.
compressedBuf_ is an unsigned char*. I've thought that the
calculation of maxBytes should be moved to the constructor,
but I have to update/improve the Resize() code first.
We've discussed the Receive function previously. I now have
a SendBuffer class and a SendCompressedBuffer class. This is
the SendCompressedBuffer version of Receive --

void
Receive(void const* data, uint32_t dlen)
{
unsigned char const* d2 = reinterpret_cast<unsigned char
const*>(data);
while (dlen > bufsize_ - index_) {
memcpy(buf_ + index_, d2, bufsize_ - index_);
d2 += bufsize_ - index_;
dlen -= bufsize_ - index_;
index_ = bufsize_;
Flush();
}

memcpy(buf_ + index_, d2, dlen);
index_ += dlen;
}

I doubt it. Making something free doesn't change your
development process. (On the other hand, if it increases the
number of users, and thus your user feedback, it may help. But
I don't think any quality problems with VC++ can be attributed
to a lack of users.)

I think it changes the development process. If it doesn't
then they probably haven't thought much about the implications
of making it free. They are in a battle of perception. Many
people have thought that Microsoft is a greedy company that
makes mediocre products. Giving away some software, while
going against their nature, is done, I think, to help improve
their image. They are forced into what 25 years ago would
have been unthinkable. I don't really think it will radically
improve their product either, though. As I've indicated I
don't think they are coming to the decision because they've
had a change of heart. It's more of a necessity being
imposed upon them. However, as I often say -- better late
than never.



Brian Wood
http://webEbenezer.net
(651) 251-938

 

[James Kanze]

Bespoke software may. But go to a store that sells discs in
boxes, and tell me with a straight face that any of those
boxes contain software developed through a development
operation which adpoted all of the best practices.

I've already stated that most commercial organizations aren't
doing a very good job either. There's a big difference between
what is feasible, and what is actually done.

[...]

I'm not totally sure of this.

I am. If only because such projects require a larger degree of
accountability than free software can offer. I can't see anyone
providing free software with contractual penalties for downtime;
most of the software I worked on in the 1990's had such
penalties.

 

[James Kanze]

Did you actually try using any free software back in the early
1990's [sic]?

I did.

Same here.

That's pure fantasy.

I used a couple of Linux distributions in the early nineties,
and they worked better than commercial UNIX variants.

And I tried to use them, and they just didn't stop crashing.
Even today, Linux is only gradually approaching the level of the
Unixes back then.

I used emacs and knew many who used vi back then. They were
solid.

I used vi back then. It didn't have many features, but it was
solid. It was also a commercial product. Emacs depended on the
version. Some worked, some didn't.

I used gcc by the mid-90s and it was rock solid, too.

G++ was a joke. A real joke until the mid-1990's. It was usual
to find more bugs in the compiler than in freshly written code.

I used free software even as far back as the late 80s that
worked beautifully.

The facts to back up your assertions are not in evidence.

They are for anyone who is open and honest about it. I did
compiler evaluations back then, so I know pretty well what I'm
talking about. We measured the differences.

 

[James Kanze]

Nonsense.

The more channels you have available, the better communication
works.

IMHO, this is not generally true. Of course, I'm autistic, so
I'd naturally think that.

There are probably some special exceptions, but other peoples
expressions and gestes are a vital part of communications.

Not to mention the informal communications which occur when you
meet at the coffee pot. I've worked from home, and in the end,
I was frustrated by it because I was missing so much of the
informal communications which make things go.

But I've been watching a lot of code reviews (our review
process has named reviewers, but also has reviews floating
about on a list in case anyone else sees something of
interest, which occasionally catches stuff). And what I've
seen is that a whole lot of review depends on being able to
spend an hour or two studying something, or possibly longer,
and write detailed analysis -- and that kind of thing is
HEAVILY discouraged for most people by a face-to-face meeting,
because they can't handle dead air.

That sort of thing is essential for any review. You do it
before the face-to-face meeting. But the reviewer isn't God,
either; the purpose of the meeting is to discuss the issues, not
to say that the coder did it wrong.

Certainly, discussion is essential to an effective review.
But discussion without the benefit of the ability to spend
substantial time structuring and organizing your thoughts will
feel more effective but actually be less effective, because
you're substituting primate instincts for reasoned analysis.

I really don't think that one can be beaten. If what you need
for a code review is for someone to spend hours (or possibly
days) studying some code and writing up comments, then trying
to do it in a face-to-face meeting would be crippling. Once
you've got the comments, you could probably do them
face-to-face, but again, that denies you the time to think
over what you've been told, check it carefully, and so on.
You want a medium where words sit there untouched by the
vagaries of memory so you can go back over them.

You do need people who are willing and able to have real
discussions via text media. That's a learned skill, and not
everyone's learned it.

It is not universally true that discussion "works best face to
face".

Almost universally. Ask any psychologist. We communicate
through many different channels.

 

[Seebs]

I am. If only because such projects require a larger degree of
accountability than free software can offer. I can't see anyone
providing free software with contractual penalties for downtime;
most of the software I worked on in the 1990's had such
penalties.

I think it may be done occasionally. Certainly, if I had contractual
penalties for downtime, and my choices were Windows or Linux, I'd
run free software.

-s

 

[Seebs]

And I tried to use them, and they just didn't stop crashing.
Even today, Linux is only gradually approaching the level of the
Unixes back then.

I guess it depends on which unixes, and which Linux. When I went from
SVR4 Unix to NetBSD, though, I had a LOT less downtime.

I used vi back then. It didn't have many features, but it was
solid. It was also a commercial product. Emacs depended on the
version. Some worked, some didn't.

The version I used (nvi) was nearly-rock-solid. Which is to say, I
found and reported a bug and it was fixed within a day. And I've been
using the same version of nvi that I was using in 1994 ever since, and
I have not encountered a single bug in >15 years.

G++ was a joke. A real joke until the mid-1990's. It was usual
to find more bugs in the compiler than in freshly written code.

I said gcc, not g++. And while, certainly, it has bugs, so has every
other compiler I've used. I had less trouble with gcc than with sun
cc. I used a commercial SVR4 which switched to gcc because it was
noticably more reliable than the SVR4 cc.

They are for anyone who is open and honest about it. I did
compiler evaluations back then, so I know pretty well what I'm
talking about. We measured the differences.

I do not think it is likely that implying that anyone who disagrees
with you is being dishonest will lead to productive discussion. My
experiences with free software were apparently different from yours --
or perhaps my experiences with commercial software were different.

Whatever the cause, the net result is that by the mid-90s, I had a strong
preference for free tools and operating systems, because they had
consistently been more reliable for me.

-s