Re: Ruby 1.8 vs 1.9

On Mon, Nov 29, 2010 at 10:38 AM, David Masover <[e-mail]> wrote:
> Then why the fsck is he CTO of anything?
>
>> and probably doesn't care.
>
> This is the part I don't get.
> How do you get to be CTO by not caring about technology?

Because C-level execs working for any of the S&P 500 don't deal with
minutiae, and details. They set *policy*. Whether or not to even look
into the cloud services, if and how to centralize IT support, etc.

The CTO supports the CEO, and you hardly expect the CEO to be
well-versed with a tiny customer, either, would you?

Oh, and he's the fall guy in case the database gets deleted. :P

>> Together with the usual
>> bureaucratic infighting and processes to change *anything*, you'll be
>> SOL most of the time. Alas.
>
> Which is, again, a point I'd hope the free market would resolve. If there's a
> way to build a relatively large corporation without bureaucracy and process
> crippling actual progress, you'd think that'd be a competitive advantage.

There isn't. The bureaucratic overhead is a result of keeping a) a
distributed workforce on the same page, and b) to provde consistent
results, and c) to keep the business running even if the original
first five employees have long since quit.

It's why McD and BK can scale, but a Michelin star restaurant can't.

> And the reason is clear: Something blows up in a C program, it can affect
> anything else in that program, or any memory it's connected to. Something
> blows up in the kernel, it can affect _anything_.
>
> I'm also not sure how much of that knowledge really translates. After all, if
> an organization is choosing C because it's the "safe" choice, what are the
> chances they'll use Git, or open development, or any of the other ways the
> Linux kernel is managed?

None to zero. But C is older than Linux or Git, too. It's around for
quite a few years now, and well understood.

>> Production, these days, is Just In Time. To stay with our steel
>> example: Long before the local county got around to nodding your
>> project through so that you can begin building, you already know what
>> components you need, and when (since you want to be under budget,
>> and on time, too), so you order 100 beams of several kinds of steel,
>
> So what happens if they cancel your project?

At that late a stage, a project doesn't get canceled anymore. It can
be postponed, or paused, but it rarely gets canceled.

You don't order a power plant or a skyscraper on a whim, but because
it is something that is *necessary*.

And the postponing (or cancelling, as rarely as it happens), has
extreme repercussions. But that's why there's breach of contract fees
and such included, to cover the work already done.


> Shaving a couple seconds off is beside the point. The question is whether
> there's some fundamental way in which the process can be improved -- something
> which can be automated which actually costs a large amount of time, or some
> minor shift in process, or small amount of knowledge...

That assumes that anything *can* be optimized. Considering the
accounting standards and practices that are needed, the ISO
certification for ISO 900x, etc. There is little in the way of
optimizing the actual processes of selling goods. Keep in mind, that
IT isn't he lifeblood of any non-IT corporation, but a means to an
end.

> Another contrived example: Suppose financial records were kept as text fields
> and balanced by hand. The computer still helps, because you have all the data
> in one place, easily backed up, multiple people can be looking at the same
> data simultaneously, and every record is available to everyone who needs it
> instantly.
>
> But as soon as you want to analyze any sort of financial trend, as soon as you
> want to mine that data in any meaningful way, you have a huge problem. The
> query running slowly because it's text is probably minor enough. The problem
> is that your data is mangled -- it's got points where there should be commas,
> commas where there should be points, typo after typo, plus a few "creative"
> entries like "a hundred dollars." None of these were issues before -- the
> system did work, and had no bugs. But clearly, you want to at least start
> validating new data entered, even if you don't change how it's stored or
> processed just yet.
>
> In a modern system, adding a validation is a one-liner. Some places, that
> could take a week to go through the process. Some places, it could be pushed
> to production the same day. (And some places arguably don't have enough
> process, and could see that one-liner in production thirty seconds after
> someone thought of it.)
>
> To retrofit that onto an ancient COBOL app could take a lot more work.

Why do you think the Waterfall Process was invented? Or IT processes
in the first place? To discover and deliver the features required.

That's also why new software generally is preferred to change existing
software: It's easier to implement changes that way, and to plug into
the ERP systems that already exist.

> I don't know enough about steel to say whether it's relevant here, but I have
> to imagine that even here, there are opportunities to dramatically improve
> things. Given an opportunity to make the change, in choosing whether to
> rewrite or not, I'd have to consider that this isn't likely to be the last
> change anyone ever makes.

If a steel cooker goes down, it takes 24 to 48 hours to get it going
again. It takes about a week for the ore to smelt, and to produce
iron. Adding in carbon to create steel makes this process take even
longer.

So, what'd be the point of improving a detail, when it doesn't speed
up the whole process *significantly*?

> The depressing thing is that in a modern corporation, this sort of discussion
> would be killed reflexively by that conservative-yet-short-term mentality. A
> rewrite may or may not be a sound investment down the road, but if it costs
> money and doesn't pay off pretty immediately, it's not worth the risk at
> pretty much any level of the company. Not so much because it might not pay off
> ever, but more because investors will see you've cost the company money (if
> only in the short term) and want you gone.

Agreed.


> I can only wonder how well that works when the veteran cookers retire. Does
> that knowledge translate?

Yup. Their subordinates acquire the knowledge. That's how trades are
taught in Europe (in general): In a master-apprentice system, where an
accomplished tradesman teaches their apprentice what they know (used
to be that a freshly minted "Geselle", as we call non-Masters,
non-apprentices in Germany, went on a long walk through Europe, to
acquire new and refine their skills, before settling down and have
their own apprentices; that's how the French style of Cathedral
building came to England, for example.)

> I've definitely learned something about steel today, though. Interesting
> stuff. Also good to know what I want to avoid...

Just take what I say with a grain of salt. The closest I got to an
iron smelter was being 500 yards away from one when it had to do an
emergency shutdown because the power cable broke.

> Which is kind of my point. Why did they upgrade? While it's true that it's
> relatively cheap, and they may also be monetizing their customer's data, I
> have to imagine at least part of the reason is that they were feeling the
> pressure from Gmail.

Absolutely! GMail did lots of good at reinvograting a stagnat market.

-- 
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.