From: Phillip Gawlowski Date: 2010-11-30T17:31:29+09:00 Subject: Re: Ruby 1.8 vs 1.9 On Mon, Nov 29, 2010 at 10:38 AM, David Masover 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.