Is Google a public utility? Do the words apply?

The words that matter would be the words written in constraining regulations -- that's what makes a public utility what it is, the fact that it is under the purview of a regulatory authority, i.e. some aspect of government.

In Australia for many years the privately held power companies had an excellent time of it -- egregious anticompetitive behaviour including cross-state price fixing on a grand scale. Look up the name "NEMMCO" for a history. It's interesting, although not terribly pretty, and not a part of our history I'm proud of.

The result of all this unconstrained trading (Oooh... the power! The Power!) did not escape the notice of the people though and regulations were written. This is what turned a number of private companies into a public utility (oddly looked after by a private company, but hey, that's Australia!).

The point I'm turning here is that Google has a huge amount of influence, and a subtle but potentially catastrophic and unbalanced control over what is seen by a segment of the population that is nearly planetary in scope. If they don't adhere closely to their "Don't be evil!" motto then they will have regulations written to constrain them.

I'm utterly convinced that this would be a bad thing, too -- I believe that Google and other search engines are the equivalent of a free press and should forever remain apart from government control -- but not all control. The best newspapers were those that knew when to tell the government to go to hell, and would stand up for their principles and their customers and content providers.

Note that word -- it's a biggie. Principles. Google has at least one, and it's the main reason why I've chosen to use them in preference to others. If Yahoo or Alta Vista or others of that ilk copy it (is imitation always so bad?) then perhaps I'll be more eclectic in my choices. But a free press still matters to me, and a free Internet. And the Internet is one very, very big book to try to get through without an index.

"Don't be evil" is simple and unambiguious -- you might differ in what's evil and what isn't, but you'd always be able to go back to that simple statement and measure your behaviour against it.

In the long run, it just might be enough to keep Google a force for good, and out of the clutches of the regulators -- if they mean it, and if they keep their self-control.

Project Scuedules Are Still Monolithic Code

A mature approach to project interdependencies is required Thesis A mature approach to project interdependencies is required today, over and above the well-known issues of resource leveling. Syllogism Schedules start with estimates. Usually these are highly arbitrary, inaccurate, and typically underestimated. Effort is a number often pulled out of the air, due to constraints of time to prepare and a keen eye toward winning the bid. Multiple organisations involved in any single delivery will have process dependencies among them. Each organisation has only part of the overall schedule Organisations do not communicate well between each other. This becomes worse when the organisations are separate companies. Organisations do not communicate issues well among each other, often concealing issues until it is too late for the other organisation to plan for change. Thus when schedules slip, it often comes as an unpleasant surprise. The higher you go in an organisation, the greater the surprise. During the process of each organisation’s independent view of the overall schedule, the business sponsors will refine their needs by approving changes to scope (change requests). These are typically sensitive to the business case (e.g. opportunity cost), but not sensitive to impact on delivery schedule. Engineers (used in the general sense) refine the estimates as they discover more detail about the project requirements. Administrators refine their view of the schedule by adding more deliverable documents. Human churn will refine the schedule by impacting the validity of estimates of required effort, adding time for recruitment and learning effort. Therefore Schedule dependencies and inter-group communications costs always increase at a hidden rate, to the point where the difference between baseline and schedule is not only broadly skewed, but becomes perceived as difficult (if not impossible) to correlate the two or to forecast a result. Commentary This makes executives edgy and desirous of outsourcing anything they possibly can, in the interests of being able to fix their costs and not spend valuable executive calendar space on non-core items. Whereas this seems like a good idea to the leather-chair set, it is not the best way to contain costs and can make delivery even harder to predict. Project schedules are, in fact, in a state analogous to the development of computer program code in the 1960’s, before the structured techniques permitted control over the logarithmic expansion of costs that monolithic programs imposed in both development and maintenance. Just as multiple programmers would have to edit a shared program in the past (think – no modules, just cut a bit here, add a bit there… then go through the nightmare of regression testing) modern project managers have to integrate a number of disparate development schedules into one single monolithic structure based on a common calendar that all must share. All the issues mentioned in the syllogism above that skew projects – let’s call them DC (Dependencies and Communications) are having the same effect as the dreaded GOTO had on the monolithic program code of the past. They make the overall project a very uneven affair, fraught with crises, unhappy employees and unhappy executives and costs that often expire the business case before anyone realises they’ve been had. Similarly to the monolithic code metaphor, different organisations will have their own fragments of the overall schedule to manage. There will be overlap as they apply faulty or out of date estimates they suspect the other organisation will apply (if they think of it a all, which is not as common an event as one would wish) . Inaccuracies become project noise, just like unfactored code becomes noise in a program. To solve the issue with code, engineers changed the way they did business. Monolithic code evolved into modular code, which evolved into structured code, which evolved into object-oriented development. The imposition of refinements in structure evolved to the point where people could bang out a good piece of code in a very short time, knowing they would not be putting other bits of code out of joint in the process. Can we say that about today’s project management schedules? No, we cannot. We have applied some structure, some templating, some controls, but in the large view we’re still doing the equivalent of many hands editing the same program listing. Tasks are very similar to lines of code. Let’s continue the metaphor, shall we? Imagine if we could apply the evolution Monolithic-->Modular-->Structured-->OOD to project schedules… would we be able to achieve the same economies of project delivery that the coders evolved? Imagine little boxcars as below, each schedule element containing many task steps, all running on the common rail of the calendar. Let’s ignore parallelism at the moment, although that can be accommodated by the model: [Sched1]..DC..[Sched2]..DC...[Schedn] --O—O-- --O—O-- --O—O-- <--Note the clever ascii wheel graphics ;-) I’d like to call these individual schedule fragments “Boxcars”[1]. The metaphor still holds true if you consider the coupling between each Boxcar as a highly elastic set of forces that send sinusoidal impacts back and forth up and down the line, similar to the starting of a large train with lots of differently weighted rolling stock. It’s always chaotic as you first start. Get the balance wrong, or the couplings too elastic and the resonances never stop and throughout the entire journey enormous amounts of energy are used up changing direction. I told you the metaphor held up, didn’t I? It still works even if you have multiple tracks. You just add couplings side to side, and the whole complex rubber-bands its way forward. It would be much easier, more subject to control, if you simplified the couplings a bit, wouldn't it? Would it be possible to move project schedules down the same path as structured code went, to modular schedules, structured schedules, or further refinements in structure? I think it's worth thinking about what sort of structure would improve the decomposition of the grand schedule, would improve the communications between the disparate elements. So think about it. Call it the Boxcar Approach for want of something better. [1] In respect to the seminal work of IT humour by the Firesign Theatre, “I Think We’re All Bozos On This Bus”. Don't know when it was copyrighted, but it was, and it was published somewhere in the punch-card era. It will be in some boomer's record collection.

I wish Windows had logical names, like VMS did

It would be so much easier to manage storage if the simple idea of logical names (any VMS people out there will know *exactly* what I mean) were available to Windows users. Think of moving an application or business group from one file share to another. File "shortcuts" simply don't make it. They're not transparent enough.

Spreadsheets Considered Harmful

There's something fundamentally flawed in our IT setup here in the bank. People are going the looong way around to avoid putting anything in a database. Why? It's not complexity, or lack of fit for purpose, or unavailability of tools. Or, for that matter, the marriage of financial people to the spreadsheet model -- they know as well as anyone the limitations of that interface. It's just that the databases are kept locked in the "shared services" locker, and thus unavailable to mere mortals. Mere mortals can control their spreadsheets, though, and struggle hugely -- and expensively -- to make them function as databases. If we can't get anything out of IT in less than six weeks, perhaps we can contact them through the 4th dimensional extension of VBA. Our systems would profit hugely by use of SQL server with a few UI tools. Little databases here and there -- not some monolithic OLTP system, but a few scattered around would be extremely useful. One simple method capsule would be to (a) use Access to develop the prototype (a friendly interface); (b) Upsize the database to SQL Server using the wizard, and (c) throw away the Access part and build the database into something useful using SQL tools. Set them up as a data source (or even use hard network folder pathing) and talk to them via any of the huge range of tools designed for the purpose. Who knows -- the applications may end up being robust, multi-user and scalable, despite being developed by the business group.

Refine the problem until it goes away

"We need a security system." said Allen, the CIO. "Fences, lights, cameras, dogs, the whole lot. Our whole livelihood is at stake here." So his offsider sends it to Strategic Sourcing for a quote. They notice we have a perfectly good fence around the garden, and lights are expensive so they cut that component based on a pre-existing policy. They notice that the department already has a camera, a Polaroid bought in 1981 but still not written off (they should have followed procedures instead of going outside the system). Dogs were a special problem - how many did they need? A good guard dog obviously, but local ordinances don't permit barking after 9pm, so they send their needs off in an RFI to a dog breeder saying they need a good, quiet dog for a fenced in area. Bite? No, we don't want one that bites, no certified dog handlers on the premises to my knowledge. Eighteen weeks later after a lot of unspecified construction having to do with automated water systems and lawn refuse pillars (complete with instructional pamphlets and custodial experts) a man from the local pet shop walks in and hands the CIO a poodle.

How do you calculate risk on software age alone?

How in the heck can you calculate risk if your only input is the chronological age of a software system? An ancient development meme referred to as "bit decay" might give a bit of insight. This says that "any piece of software, if left to itself, will eventually fail to work". Implied was the idea that the software may not change, but the surrounding factors do; e.g. a tape-based system works fine until someone replaces the tape drive with a slightly different model, forcing idiosyncratic code to fail where it depended upon idiosyncratic features of the hardware that were factored out in the next engineering change. People try to avoid this with software change, but it rarely works -- hard to motivate people to check old code exhaustively. Perhaps a simple rule of thumb -- "nobody does it that way anymore" should take precedence over "it was good enough for grandpappy and we haven't depreciated that asset and nobody died from it yet". Perhaps I'm just growing cynical -- but that's better (by my reckoning) than growing stale. But I know that rule of thumb has traction among the development community, who generally know better -- it's their pond we're swimming in, folks, irrespective of what the business case concludes.

Cold War begets Hippy Culture begets Personal Computer

Most of the hippie culture was initiated by educated people who wanted something different from what they had, which was a regimented culture veering toward suppression of individuality. The counterculture wasn't all drugs, wasn't all "protest" but was simply stuff that was different. There weren't a lot of anchors to hold on to (the culture we were attempting to escape was pretty hollow) but a few luminaries managed to publish things to fill the cultural vacuum of the times -- things like the Whole Earth Catalog, whose motto was "Access to Tools", not "We Protest". The cover was planet Earth, shown from orbit. It contained technology -- beautiful stuff, from hand-held power plows to the first PC's to cheap land cruisers. I submit that the WEC was more symbolic of the counterculture than the Time magazine articles that formed the basis of much of the public perception of the movement. A lot of software developers started then, when - again - the rules were being challenged, and the people vacuum in the industry became attractive; few colleges knew what a CS degree should even look like, but the counterculture also espoused "Look, you can do it, give it a try" and encouraged people to step out of the ego-crushing conformity pressed on the public via wide dissemination of corporate advertising memes, e.g. the barely-subliminal messages coming out of GM advertisements (Longer! Lower! Wider!). As a result, people were encouraged to think out of the box for the first time in a long time, a necessary breakout from the corporate-government-proprietary wartime morality that lasted well into the 50's. The world around us was pretty grey -- McCarthy was in power. Down at the bottom there were people saying I can have power too, I can be empowered, I'll be a computer programmer and it doesn't require me to compete at the beach to be important. That's what drove the counterculture into adopting the PC as a causus belli. Sorry about the stereotype, but the geek cliche came from that. Nullus stercus, ipi eram.

Financial systems analysis as a MMRPG

There's a very popular online game called Everquest (Yes, I play it. Xegony server, if you must, but I'm afk atm) where people go on a series of seemingly mindless quests for odds and ends which, when turned into the appropriate non-player-character (or NPC) give you a bit of advantage into the game. A bit of experience (a quantifiable commodity, but then again this is a fantasy) perhaps a bit of coin, or a new bit of armour or weaponry. How is this different from financial systems analysis? The online game is a bit more structured and has less of a dress code, but otherwise not much. In the world of finance, you are constantly seeking bits of paper and delivering them to what appear to be non-playing characters, only to be rewarded with another piece of paper that you have to get signed, thence to deliver it to another non-playing character (say, an Auditor). For this, you get Experience, and maybe a little money. There is a form of stylized combat, where you go up against other players to compete for budget or to shortcut a process (a rare drop, that) and the major value you get for your experience is learning how to navigate through the institution that's paying you real money for real things, like food. There are places (just like the game) where you only want to go in armed, and in groups -- especially if you're an auditor (no, I'm not ... although I understand the need for them, as there are some things lab rats simply won't do). There are huge fields where the challenges come at you with the intent to kill you (or your career) for their own advantage. If your group is strong, and you pick your battles, you can win. If not, you find yourself at the home point looking for some form of resurrection, bereft of weapons and armour and funds, seeking a magic rock that can restore you to your former glory.