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.

What is a workflow system, really?

• A set of status attributes on data entities;
• A set of rules upon which those attributes may be changed
• A set of user-oriented filters and alarms used to display relevant data to end users, via their visibility in various forms and reports.

Honestly, it isn't rocket surgery. People pay vast amounts of money for workflow systems and underlying each of them, there are these three principles.