JasonB (no@spam.com) on 8/28/09 wrote:
---------------------------

>Likewise, the intrinsic difficulty to managing errors well in a large system
>without exceptions was precisely the motivation for inventing exceptions
>in the first place. They are designed to make error management easier, not
>to make the problem go away entirely. As I said, education seems to be called for,
>not avoiding a tool because people have misconceptions about it.

Oh, I know that was the *intention*. I just think that
goal was not achieved. Just as you think the Java
exception-type stuff is too cumbersome to be useful
in practice.

>The Peter Principle?

Not exactly. Good developers are smart, usually have
excellent memories and analytical skills, and are accustomed
to considering many different solutions. The ones who
also have reasonable people skills make excellent
managers. They can be perfectly competent in that role -
but then they're not writing (so much) code any more.

> It's also why I
>think that management positions should not be the only way >of rewarding particularly
>good employees -- if someone is most valuable as a >developer then keep rewarding them for that.

Yes. Happily my employers allow technical people to
keep getting promoted without taking management
responsibilities. It's a good idea.

>I'd have serious reservations about the long-term >competitiveness of a company
>that persists in hiring poor quality staff

Yes. But when the bean counters say
you can get 3 developers in India for the cost of 1 in
the USA, everything we should have learnt from "The
Mythical Man-Month" tends to get forgotten. Not that
offshore developers are dumb - a lot of them are smart -
but they're often inexperienced, and distributed
development makes it hard to get everyone on the same
page. Anyway, my point was that the demographics of
the developer population ensures that the *majority*
are going to be not so great: if you can hire 90% of
your staff from the top 20% of the population, you're
fine. But that's a really difficult trick, at least
for a team of more than 10 or so.

I think the one factor that saves the whole software
world from complete chaos is that the top 20% of
developers (in competence) actually end up writing
probably 80% of the code - including the most complex
parts. The less competent write less code, and much
of what they write gets thrown away.

>then we would fix that problem. Gradually, over a period of several years, it got
>better. Adding uses of scopeguard or replacing all uses of FILE with stream objects
>implementing RAII makes your code just that little bit more robust and easier to
>maintain even if it doesn't fix the entire thing overnight.

That's fair enough. But if you're starting from the
point of *not* using exceptions, then the changes don't
add any actual value until they're pervasive enough that
you can start using exceptions. So that's a pretty high
bar, and telling people to do something that costs effort
right now, but *might* yield a benefit in future, is not
very compelling.