From: Phillip Gawlowski Date: 2010-12-01T23:44:28+09:00 Subject: Re: Ruby 1.8 vs 1.9 On Wed, Dec 1, 2010 at 2:40 AM, David Masover 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). >> 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. Absolutely. But it's the big picture, rather than the performance of a single salesperson / developer. >> >> 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. >> 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. 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. > Nothing's stopping you from switching contractors, or switching to a different > approach entirely -- there's more than one way to get power. That has been decided before the first contractor is hired. Consider the cost of even planning a power plant or a skyscraper. That's a lot of sunk cost if you switch horses mid race. >> 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? When the plans for the product are agreed upon. A project can fail before that, but not after the bid for contracts has ended, at least not easily, and certainly not cheap. > 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. Absolutely. The microprocessor revolution *was* a revolution, and VisiCalc changed the way the game was played, just as DTP reduced the cost, and made it easier, to create marketing brochures, for example. > 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. > 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. Most large IT projects fail because requirements are unclear, or change. XP, agile, and scrum want to change that, but that doesn't necessarily happen. You have to keep in mind that the problem domain is well understood by the stakeholders, and well enough to formulate processes, and to run a business. Ancillaries might change (like how accounting standards, if, how, and when payroll taxes are collected, and so on), but in general, these sorts of problems can be anticipated, and planned against. It's not rare that, say, GM would switch health insurance providers, or had to deal with different health insurance providers, so you keep your software flexible enough to manage these changes. Production costs can change, as can the parts required to produce, but, to put it bluntly, only the variables that you plug into the equations to know how many X you need to produce Y change. Determining what a production run would cost, and what you need to deal with isn't that difficult (it comes down to multiplying matrices with each other, more or less), and thus you know how many units you can sell at which price. Computers make this easier, but they didn't change the essentials of business economics. 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. And while these can change (IIRC, New York is reworking its approach and departure vectors for the NY airports), it takes a long time to arrive, and then implement these changes. There's plenty of time to adjust, and it's not, in a sense, business critical for United Airlines from where the planes reach their destination. What is important is that more planes can put into the same space without increasing the risk, but that's not something new, either (TWA and PanAm were locked in a furious war over trans-Atlantic routes after WW2, for example). Where things get absolutely tricky, is when you have to integrate business processes of different corporations, after a merger or an acquisition, but that's something that takes years, too (like Google's acquisition of FeedBurner or YouTube, or AOL buying TimeWarner, or Thyssen and Krupp merging). -- 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.