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-30 05:04 +0900 (Wed), Stephen J. Turnbull wrote:

> Second, you seem to be back to that argument, but what I'm saying is
> that the team leader has *already* done the best she can to improve
> the current team's productivity, but has been asked to perform a task
> that is too big for it.

What you don't seem to realize is, they might just be f*cked. "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.
The industry, or at least some in it, have known this for a long time.

I'll be the first to admit that Brooks's law is more of a statement of
what often happens than a law, and there are cases where, depending on
the type of development you're doing, adding manpower will work. But
that type of development is often automated in the end; compilers these
days, when compared to a team of assembly language programmers, do the
job not only much cheaper, but significantly better.

Anyway, I'll state my theses here for a final time, and cease this
argument. You can say I'm wrong if you like, and all I can say is that I
hope people like you are my competitors in the software business.

    1. Some languages are more powerful and productive than others and,
    with proper training and experience, will allow a developer to do
    more work than he could with lesser languages.

    2. C, C++, Java and Python are amongst the middle range of languages
    these days; there are various other options out there that are more
    powerful and have "industrial-strength" compilers and toolsets, such
    that they are usable, or could without great difficulty made so, in
    the kind of work that Google, Amazon, Microsoft and IBM do.

    3. It seems likely that a decade or so in the future, there will be
    large companies using these better tools. IBM has shown that large
    companies make these kinds of changes (compare the number of Java
    developers in IBM now to twelve years ago) and MS is showing that
    companies now are doing the groundwork to do this in the future
    (by having a research group producing industral-strength tools for
    Haskell, and by starting to bring OCaml into mainstream development
    products via F#).

    4. Google should be aiming not to have only C, C++, Java and Python
    as their standard langauges ten years from now, because if they do
    they will have less productive developers than large companies using
    better tools (which it seems likely there will be, see above) and
    they will be less attractive to these more productive developers
    than these other companies.

    5. If Google does want to be using other tools a decade from now,
    they should be starting to work on this now, because it's going to
    take them years to figure out what to move towards and to make that
    movement.

    6. Using "our production teams can't support it" as an argument
    against letting developers start to experiment with these things is
    a backwards approach; the whole point is that not only do developers
    have to learn these languages, but production teams have to learn
    how to support and deploy products written in these languages if
    they are going to be used.

As a comment on number six above, the "production teams can't support
it" argument is silly anyway, when it comes to systems built with
toolsets such as GHC and OCaml; these are pretty standard Unix (and
also Windows, in the case of GHC) toolchains that produce the same
kinds of binaries and shared libraries as C and C++ compilers, and
interoperate with code written in C and C++ and other code that also
interoperates with those. Supporting this is an easier job than
supporting interpreters such as Python and Ruby.

Note that I'm not saying, "go wild and let anybody who wants to write
any part of our systems in Haskell." I advocate a measured approach that
uses proper risk management at all stages. But to avoid risk by avoiding
this sort of thing entirely is to take a much bigger risk over the long
term.

I think, Stephen, that the paragraph above takes into account and deals
with a lot of your objections, though you may not believe so. But I
accept that you believe that some or all of the points above are wrong,
and and we'll just have to end up at that sad point where we agree to
disagree.

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