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

[Curt Sampson <cjs@example.com>]

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.*

>  > 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.

It was sounding like it.

> 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.

> [A]nd "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?"

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.

> You've got this blind spot where hiring more people is just plain
> unacceptable to you.

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.

> 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.

These are exactly the kinds of tasks that can be and have been made far
more efficient by having a small team of smart people automate them.
"[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?

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

You're going to see a lot more of it here since, as I mentioned before,
I'm very much trying to limit the amount of time I spend on this.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com