Re: Ruby 1.8 vs 1.9

On Wednesday, December 01, 2010 08:44:28 am Phillip Gawlowski wrote:
> On Wed, Dec 1, 2010 at 2:40 AM, David Masover <[e-mail]> wrote:
> > 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.
> 
> Ideally, yes. However, I contend that on the C-level with the size of
> corporations we are talking about, issues become very abstract, and
> management reads the abstract of reports, much like the Joint Chiefs
> of Staff don't deal with the After Action Reports of a platoon, but
> with the state of the whole theater of engagement. Those require
> different skills and a different thinking (more big picture vs
> details).

It's a good analogy -- I would hope the Joint Chiefs would:

 - Be actual generals with actual experience as colonels, majors, captains, 
etc -- so they have some concept of what's actually going on at every level.

 - Keep abreast of improvements in existing technology -- if your rifles can 
suddenly shoot twice as far, that changes things considerably.

 - Keep abreast of entirely new directions -- UAVs could, again, change 
strategies considerably.

If I were to present them with a better weapon, better form of armor, etc, I'd 
hope they wouldn't just decide not to care. Maybe I'd have to talk to a 
subordinate first, but you'd hope bureaucracy wouldn't prevent new tech from 
getting on the battlefield at all.

> >> >> Together with the usual
> >> 
> >> 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.
> 
> That's neither here nor there. You can debate endlessly how much
> bureaucracy is needed, but it is quite clear that some bureaucracy is
> needed.

My original point was that I'd hope there's a way to build a relatively large 
corporation without bureaucracy and process _crippling_ actual progress. I'm 
not claiming that all bureaucracy or process cripples progress or is 
unnecessary, or that none of it carries any overhead, but certainly there's a 
difference between a mostly self-organizing, motivated workforce and one with 
two managers for every three developers.

Having a manager at all helps things, and I'm much more effective with someone 
to report to setting direction. Having so many managers that Office Space's 
five bosses becomes a reality is much more of a hindrance than having no 
managers at all.

> >> 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?
> 
> Because it enforces a uniformity of process.

Good or bad, I'm still not seeing the connection to c above.

> An apprenticeship in a
> trade teaches said *trade*, but not management skills, or sales, or a
> host of other things that are necessary to run a company.

Wait, why wouldn't an apprenticeship work in management, sales, or any of the 
other fields necessary to have a company? It seems to me that this would be a 
_better_ way to teach someone to be an effective CEO than to add so much 
process as to automate the position away.

> > It may be that all the important problems in these areas are solved, but
> > again, it seems risky to assume that.
> 
> At this point, change is more incremental and evolutionary, than
> revolutionary. Of course, something can change that, but it's not
> something I'd bet on (or against) to happen, and I certainly wouldn't
> base a business plan off of that.

But if the cost of incremental change is sufficiently high, you're not 
evolving, you're stagnating.

And maybe I'm naive, but I keep seeing small changes that have a large impact, 
especially at scale. They don't happen all the time, but they happen often 
enough that if you plan to be around for the next 50 years, you're going to 
see a few of them.

> Similar with an airline that has to deal with weather events: Weather
> always existed, and pilots deal with it. Routing is, oddly enough,
> less important: Air traffic travels in pre-determined traffic lanes,
> to minimize the risk, and to minimize the required personnel to
> control this traffic.

Given the same lanes, however, it would be useful to be able to divert either 
planes or passengers around a weather problem. If there's a thunderstorm in 
your hub, do you delay every flight through there until it's gone, or do you 
redirect people to a different hub?

Weather always existed, but that kind of thing wasn't always practical. (I'm 
not sure if it is now.)