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-30 14:23 +0900 (Wed), Stephen J. Turnbull wrote:
 > 
 > >  What *you* seem to want to avoid admitting is that they might very
 > > well not be f*cked.
 > 
 > 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.

 > I'm somehow not buying this as a convincing argument for going for the
 > lowest common denominator when hiring programmers, however.

That's good, because I'm not selling any such thing.

I'm saying "when nothing else works, why not consider hiring more
programmers?" and "supposing that when nothing else works, hiring more
programmers sometimes works, why not entertain the possibility that
there are situations where hiring more programmers is the most
effective way to expand output of software even though there are other
ways to do it?"

You've got this blind spot where hiring more people is just plain
unacceptable to you.  Of course you're not buying it, and when I try
to force you to consider a situation where that may be the only
solution, you accuse me of going after the lowest common denominator.

 > >  > "Just double the size of the developement team and we'll get more
 > >  > done" is the standard managerial response for people who don't
 > >  > understand why software development is different from engineering
 > >  > or manufacturing.
 > > 
 > > And it's the correct response: twice the size of the team can do twice
 > > as much programming (up to variations in average productivity).
 > 
 > I'm speechless, especially when something like this comes from you.

Once again, you didn't bother to read past the idea you find
offensive, I guess.  You certainly stopped quoting there, which is a
pretty nasty trick (unless you really don't understand the difference
between "output" and "productivity", which seems unlikely to me).

There are tasks where doubling the size of a small team (holding
quality constant) actually might pretty much hold man-months constant.
Writing unit tests for a large library of small modules, auditing a
large program for buffer overruns and other local security/stability
issues, maintaining multitude of Web 2.0 sites for a multitude of
small clients, etc.

 > Research needs to collide with the real world to actually help with real
 > world problems, and stuff hidden away doesn't. If it did, there are
 > signs you would see that it is. I'll leave it to you to figure out what
 > these might be and why you would be likely to notice them.

Not above adopting handwaving when it suits your purpose, eh?