Air France stops maintenance in China after screws missing from plane:

Air France suspended the maintenance of its aircraft by Chinese company Taeco after 30 screws were found to be missing from one of its planes, it said Thursday.

“Nothing about the iPod, iTunes store, iPhone, or iPad was safe. Jobs focused on upside potential, not downside risk. Like the great generals in history he preferred offense to defense.

As for excellence, he insisted on it in the technical as well as general meaning of the word. Technically, “excellence” refers to the presence of desirable features people want to buy, as opposed to “quality,” which refers to the absence of defects … a characteristic Jobs didn’t particularly care about.”

(Via keepthejointrunning.)

(Via Bob Lewis @ Infoworld)

from MobileMe <MobileMe@insideapple.apple.com>
date Wed, Mar 16, 2011 at 13:02
subject Upgrade to the new MobileMe Calendar by May 5, 2011

Upgrade to the new MobileMe Calendar by May 5, 2011

Dear MobileMe member:

On May 5, 2011, MobileMe will transition completely to the new Calendar service that we launched in October. The new MobileMe Calendar includes calendar sharing, invitations, and a new Calendar web application. To maintain calendar syncing between your devices and to continue accessing your calendar at me.com, you must upgrade to the new Calendar by May 5, 2011. Please follow these instructions to complete the upgrade …

So Fuck You Too, Me.com.

Whatever else you do, give yourself a chance: Rename every project, initiative and strategic program in your organization to reflect the business change goal instead of the system name: Sales Force Effectiveness Project instead of Salesforce.com Implementation; Evidence-based Decision-making Initiative instead of Business Intelligence Implementation. The impact is surprisingly large. – Business change methodology gaps | IS Survivor Publishing.

Here is it is in a nutshell. Too often I’ve worked on building a computer program, rather than a business system. Now as I’m a computer programmer, what can you expect? Some might say, “well, I don’t want to know about the business system, just let me code”. And in some circumstances they could be right. But the thing I find is, that often the layers of people, business analysts, architects and managers are rarely thinking about the business system either, and that’s not even usually their fault either. Someone may have, long before project inception, thought they needed a “business change goal” as Bob Lewis puts it, but within a few minutes it is articulated as “we need a computer system to do X and Y” and ever since, that’s what’s been firmly in mind of everyone involved in the issue.

I always find the most useful question to ask any end-user, project manager, architect, business analyst etc, when clarifying ambiguity with them is not “what do you want the computer to do at this point?” but more importantly, “what goal are we trying to achieve?”. This allows me to formulate at least a couple of scenarios as to what the computer should “do” and allow the user to choose the most appropriate one.

This issue has become more and more apparent to me as I’ve been working these past few months on a important, high-visibility project inside a highly visible brand/player in Australian transport. The stuff I’m doing directly impacts the physical operation of the company’s equipment (and the equipment, on it); unlike most other systems I’ve built which are typically about shuffling information – usually monetary – about the place. The software I’m building has the ability to make hundreds, if not thousands of employees’ jobs easier to perform, create better integration between the company and the company’s vital partners, and maybe earn a little bit of kudos with the company’s customers as well (as they definitely use the outputs of the system). But the systems we are building are defined narrowly in scope in terms of just software components with quite limited goals. Talking to the end users and the business sponsor, when they express their needs in terms of what their jobs requires, you can see this vast field of lacunae and we’re not even impacting 10% of that. It’s frustrating to be telling them the usual mantra: “out of scope in this project”. Yet it also appears that at least certain members of management had attached a cargo-cult to the project, in that they thought it would magically solve a bunch of problems that it was never addressing, all the time while reducing the scope. Those false expectations have had to be hosed down in fairly short order. So while the need is clearly apparent to everyone involved, I certainly don’t see any effort to create a bigger “business change goal” anywhere articulated, even though its desperately needed.  Even if there is one somewhere in the higher echelons of management, there’s never been a a plan that tells us down here in implementation just where our project fits in, and how to shape it appropriately to meet those bigger goals, which is an issue. This is not just about strategic vision, but tactical necessity.

I’ll leave you with another quote from Bob’s article about the issue of “politics” (and I’m not saying that my issues above are “political”, there’s just organisational failure issues):

Politics isn’t a thin, unpleasant veneer — a distraction from the “real” work of organizational change. It constitutes, by its very definition, a great deal of the real work of organizational change.

Oh for people who know what company I’m currently engaged at, none of the above has anything to do with recent “issues” that have been in the media about that company either. It’s a deeper sort of malaise, one that’s particularly frustrating because you can sense that maybe there’s some chance that they they could be just this close to actually “getting it”, at least in regards to the project I’m on and the people whom it directly impacts.

• is afraid of change
• not interested in improvement
• has a rigid top-down process development style
• doesn’t care what you think

I think the greatest problem is the organisation basically doesn’t trust it’s employees to know what they are doing. It doesn’t matter that you may know something better or that you care about improving the company’s performance.  I find when I hear this sort of phrase from in companies I’m consulting at, you soon discover all manner of other issues, idiotic decision making processes, strange convoluted internal processes, inflexible management styles, complete reliance on reporting and long meetings for project visibility, and completely rigid thinking.

What the upshot of all this is, is usually a company that then is left with workers that accept their situation rather then improving it. Ultimately, when such companies confront the reality of their situation and require change to avoid failure, they fail because their employees don’t want change – they’ve had it ground down out of them over the years.

Stasis as a corporate strategy only works for so long.

DAVID DUNNING: Well, my specialty is decision-making. How well do people make the decisions they have to make in life? And I became very interested in judgments about the self, simply because, well, people tend to say things, whether it be in everyday life or in the lab, that just couldn’t possibly be true. And I became fascinated with that. Not just that people said these positive things about themselves, but they really, really believed them. Which led to my observation: if you’re incompetent, you can’t know you’re incompetent.

ERROL MORRIS: Why not?

DAVID DUNNING: If you knew it, you’d say, “Wait a minute. The decision I just made does not make much sense. I had better go and get some independent advice.” But when you’re incompetent, the skills you need to produce a right answer are exactly the skills you need to recognize what a right answer is. In logical reasoning, in parenting, in management, problem solving, the skills you use to produce the right answer are exactly the same skills you use to evaluate the answer. And so we went on to see if this could possibly be true in many other areas. And to our astonishment, it was very, very true.

Recently I was learning ANTLR, trying to decide whether this was a right technology to pursue a particular project which involved parsing a preexisting message format. After a week of a spike, we decided that it was worth pursuing and started on earnest on the grammar for our project. However a week into this process, I had an epiphany … I was doing some things wrong with the ANTLR grammar which were now slowing progress in adding the new characteristics it needed to be complete. Many developers know this feeling; the features of my grammar that I had built over the first week were naive and now hampering it from expanding into the new requirements. I took it on myself to kill the entire grammar and start again. It took less than a day and half to replicate that week’s worth of work (i.e. pass the test suite which had built up around it).  I’ve done this before; scrap the first attempt at building a domain and try again. Here my domain was the same (it was after all defined in both a standards specification and in the many hundreds of thousands of sample messages we captured from an existing system), but its implementation needed refinement.

So I think that the rule about throwing away spikes can in fact be made a general axiom of programming:

When you are learning a new technology, make sure you throw away the first thing you build that works – to avoid accumulating your mistakes.

Thanks to Robert for the important qualifier “that works”.

N.B. my views about system rewrites have not changed regardless.

I don’t hold that software makes an existing business process “efficient” at all. Rather I think software makes possible a new process, which should be more “efficient” in terms of money gained less dollars spent – but its a new process, not the old one. In effect, new software creates new business opportunities. New software will only make an existing, unchanged process, less efficient, if a new business process is not designed along with the new software. If the business just wants new software without changing “what they do” they are wasting their money, IMHO.

Of course there is the possibility (probability?) the business doesn’t actually understand what it is they actually do anyway. This is not an uncommon position for many businesses that are happy to cruise along in neutral making some marginal profit on some marginal activity. Usually these businesses are also found to be beating their workers with sticks (usually only metaphorical ones unless they ‘offshore’ their operation to countries where killing your workers is just a part of ‘Business as Usual’. Typically they hold that marginal process can be made ‘better’ simply with just more exhortation (or threats) to greater and greater efforts at a totally demoralized (if not actively hostile) workforce, but I suspect that’s a story for another day!