Re: work times & accommodation @tokyo, WAS: Re: [tlug] Embedded linux dev wanting to find work in Tokyo.. Seeking advice.

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:
 > On 2008-07-31 07:16 +0900 (Thu), Stephen J. Turnbull wrote:
 > 
 > > Curt Sampson writes:
 > >
 > >  > The more inefficient they are to begin with, the better a chance they
 > >  > have of being able to expand quickly by just adding more people, yes.
 > > 
 > > Actually, that's probably not true.
 > 
 > Well, I disagree. *Shrug.*

My point being that if they're that inefficient, they're probably at
the bottom of the man-month frontier anyway.

 > > I'm saying "when nothing else works, why not consider hiring more
 > > programmers?"
 > 
 > Which of course I do. But that's a long, long, long way away from
 > deciding that, in general, your're going to scale things by hiring more
 > programmers.

Where have I suggested that?  I'm saying that it's not obvious to me
that Google isn't in a particular situation where increasing output is
best done by hiring.  Agreed, Google's been growing by hiring and
acquisition long enough that "they're smart, so they're probably doing
the right thing" has worn out its welcome, and it's time to suspect
mere strategic inertia.  But you (or whoever) need to prove that
suspicion.

 > It really depends on what situation you've put yourself in. At any
 > particular point, quickly hiring a large fraction of the number of
 > programmers you currently have may be effective. However, I'm saying
 > that if that strategy works for you in general, in the long run you're
 > almost certainly less efficient than people who are automating those
 > programmers' jobs so that computers can do them.

Efficiency may not matter, though.  At Google scale, it may only
matter that they get the job done, as long as the few guys at the top
are choosing the right job.

 > Nope. I'm just saying that there are other, better, options for
 > producing more useful software in the long term, and you should be
 > working on those because otherwise you'll fall behind. Go back to my
 > 6-point (or whatever it was) argument summary and tell me what you
 > disagree with from there.

I don't disagree with any of it in general.  I don't see any really
large companies following it on a large scale, though, and that makes
me wonder if it scales.  What I'm hoping you would do is provide me a
reason to believe it *does* scale to the case where companies have a
workforce growing at 25% or more per year for several years.

What I do see is large companies "keeping up" with 10 to 15-year old
technology.  C really didn't take over the world until 1985, C++ until
1995, Java until 2005 (don't take the numbers seriously).  I sat in on
a seminar where one of my colleagues was trying to teach Java in 1992,
but the most popular languages remain Excel, FORTRAN[sic], Emacs Lisp,
and C/C++ in about that order.  (Admittedly we're not a programming
shop, but allegedly we're trying to teach people who are very likely
to end up managing programmers.  Go ahead, laugh, it's only a Japanese
ex-national university with pretensions of MIT-hood, after all.)

 > "[A]uditing a large program for buffer overruns" is the classic example.
 > Would you rather hire twenty people, at whatever level of quality you
 > can find when you need that many, and let them go at it by hand, or just
 > hire the two smartest of those and buy a copy of Purify?

Whoever said they were going at it by hand?  The fact is, even if you
use something like Purify or valgrind, or static checkers hot off the
PhD press at UCLA, the number of potential problems they report is
likely to be O(LOC).  Double the programmers reviewing reports, more
or less halve the time.

And you seem to believe that by sacrificing the Purify CD-ROM on an
altar of burned-out hard drives the evil spirits will be driven out of
the program.  Heh.  You know as well as I do that it don't work that
way.  There's a reason for the the "grind" in "valgrind", and it isn't
how hard it makes the CPU work; it's how hard it makes the testers
work.  Purify is no different, it's a runtime checker.  That means a
lot of benchwork (even if you use Coverity or gcov) writing tests that
exercise as many of the execution paths as possible.

I've also seen the output of static analyzers on a program I'm rather
familiar with, XEmacs.  Dealing with their complaints was a very labor-
intensive process, because they were often enough wrong -- but they
caught a bunch of problems that valgrind has never mentioned, as well
as verifying one or two problems that valgrind did bitch about but
we'd (mistakenly) given a clean bill of health.