Re: Ruby 1.8 vs 1.9

On Tuesday, November 30, 2010 02:31:29 am Phillip Gawlowski wrote:
> 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.

To do that effectively would require some understanding of these, however. In 
particular, "cloud" has several meanings, some of which might make perfect 
sense, and some of which might be dropped on the floor.

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

I'd expect the CEO to know and care at least about management, and hopefully 
marketing and the company itself.

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

Ideally, the person who actually caused the database to get deleted would be 
responsible -- though management should also bear some responsibility.

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

Yet Google seems to manage with less than half the, erm, org-chart-depth that 
Microsoft has. Clearly, there's massive room for improvement.

> b) to provde consistent
> results,

This almost makes sense.

> c) to keep the business running even if the original
> first five employees have long since quit.

This really doesn't. How does _bureaucracy_ ensure that more than, say, the 
apprenticeship you described in the steel industry?

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

Nothing's stopping you from switching contractors, or switching to a different 
approach entirely -- there's more than one way to get power.

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

Then what's the point of the "final approval" that you're waiting for?

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

That seems to be true almost by definition, but major improvements in IT do 
affect non-IT companies. Shipping companies and airlines benefit from improved 
ways to find routes, track packages or flights, and adapt quickly to changing 
conditions (like weather). Supermarkets and retail outlets benefit from 
improved ways to manage inventory -- to track it, anticipate spikes and 
problems, and react to things like a late shipment.

It may be that all the important problems in these areas are solved, but 
again, it seems risky to assume that.

> > 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....
> 
> Why do you think the Waterfall Process was invented? Or IT processes
> in the first place? To discover and deliver the features required.

The point of this example is that you don't necessarily know up front what the 
"requirements" are. It's not required that you be able to perform such 
analysis, and it might not have been feasible when the original program was 
written, but it's certainly valuable today.