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)

The technology world has just lost another giant, though one without the towering public persona of Steve Jobs.

If you’re not actually a programmer, you’ve probably never heard of Dennis Ritchie. But the vast majority of software you use was built using a tool that he originally designed, and the rest by tools that very liberally sample from his.

The “native language” that the central processor in a computer understands is an ornery beast. For one thing, back in the 1970s every two-bit computer company (if you’ll pardon the techy pun) had its own native language; these days, there still remain two very common ones, and dozens of less common examples out there. More importantly, it’s almost incomprehensible, even to most programmers. Take this little snippet, part of the preliminaries to a very simple program that just prints the message “hello, world” to the screen:

_start:
        mov    eax, 4
        mov    ebx, 1
        mov    ecx, str
        mov    edx, str_len
        int    80h

Writing long and complicated bits of software with such unhelpful notation is extremely slow and error-prone.

“High-level” languages, that allowed the logic of software to be expressed in more compact and readable notation, had existed since the 1950s; Grace Hopper was responsible for one of the first. Over time, more and more of the scientific and business software run on the large computers of the era was written in FORTRAN, COBOL, and other high-level langages. However, the “operating systems”, the software plumbing that joined those applications to the hardware, was invariably written in the machine language of specific systems.

In the late 1960s, Ritchie, working with Ken Thompson at Bell Laboratories, hacked together their own little operating system for an obsolete computer nobody was making use of. It was small, but it worked, and was one of the first practical systems to support “timesharing” – the ability for multiple users to run multiple programs simultaneously and interactively. Fairly early on, they had another brainwave; they would rewrite as much of the system – which became known as Unix – as possible in a high-level programming language, to speed development. But first, they needed a suitable high-level language. The resulting language, an evolution of earlier languages entitled BCPL and B, was called “C”.

Both C and Unix were raging successes, partly because of their inherent strengths. The use of C allowed Unix to be “ported” to many different computer systems, a process that continues today as its spiritual successor Linux, written in C, runs on everything from IBM mainframes (and the amphormous “Googleplex” of Google’s servers which, reportedly, draw 240 megawatts of power), to virtually every smartphone on the planet (the iPhone’s operating system is not Linux, but it is also a derivation of Unix and substantial parts are written in C). They also had the good fortune, as with the Internet and World Wide Web which owes so much to both, that they gradually escaped the crush of intellectual property law to become part of the intellectual commons of the field.

Almost as important was the elegance and economy that Ritchie, along with Brian Kernighan, brought to teaching the language. Their textbook The C Programming Language remains the best programming language textbook ever written, in my view, and the one that I still strongly recommend to my students.

Much of the Windows operating system, and Mac OS X, are implemented in C. Those parts that aren’t, are implemented in computer languages directly derived from it – C++ and Objective-C. Most of the software that runs on those systems is also written in C or its successor languages. And perhaps the most pervasive “new” high-level language of the last 20 years – Java – retains so much of C’s “look and feel” that it often takes a second glance to tell which language a piece of code is written in.

Neither C nor Unix were by any means perfect. While some of its design faults have been eliminated in its successors others remain, and will likely continue to bamboozle neophyte (and, all too often, experienced) programmers, for generations to come. But there was so much he and his colleagues got right. Fate did play its part, but there are very good reasons that generations of software developers not yet born will express themselves in notations largely based on Ritchie’s.

RIP, dmr.

First the technologies and the development methodologies.

So the first company uses a very Waterfall process and the integration platform is SOA. We’ve managed to build, in the middle of this, a small and focussed Java component that uses JMS in and out to avoid building horrible horrible BPEL or BPMN etc. But at either end, there’s some SOA bits to manage the integration with the “legacy”. So we’ve got this great bit of software, does amazing things, delivers real value to the business, which they want to put into production asap, but at every turn we’re hampered by the organisation or the technology platform. Its not so much the technology platform but the waterfall process the company has put around it. I’ve been told an internal wiki article detailing all the JMS  configuration is not  acceptable and the detail had to be in a Word document attached to an email requesting a not-production server configuration change. Word documents attached to emails are apparently far more “controllable” than a wiki with strong authentication protocols and history details in this world-view. Naturally I cut and pasted my wiki configuration detail into a Word document, spent a morning formatting it, and even added a link to the wiki before attaching it to an email. Acceptable process; configuration delivered. SOA and waterfall go together to make software development hell.

The second project has its many issues but one thing it does not have (for the components I have designed at least) is any SOA. It is all REST all the way down. There are multiple server-side-only components that all communicate to each other with REST over HTTP. Some of the data passed between servers is (or soon will be) JSON. The user interface is about to be delivered in two parts – one through actual REST-inspired web page requests to get the HTML and the other, via JQuery running on the web pages to actual JSON over REST services. These services will also call the REST services on the other components of the system (no database at the UI level). In fact many of the same JSON documents will be used to communicate from server to server as from ui to server. We are using Jersey for the REST. The process is Agile. The organisation hasn’t delivered such a large project with Agile before, and while I’ve been away on the other project there’s been some loss of focus. But despite some critical moments we had last week there’s been a renewed commitment to improving the engineering and project processes to achieve high velocity and good success. Its not perfect but it feels like the senior managers want the agile process to succeed. So, REST and Agile go together to make developer success.

Now, to the organisations. See if you can match the organisational description to the project style.

One of these two projects is a really fascinating piece of software in the transport industry (I can’t say more than that) which is integrating a number of “old” software solutions and creating some really sexy new features that the customer wants and loves. It is across what Eric Evans calls the “core domain” of the business. Not only is it a relatively short piece of work, but it will deliver high value to the business. It also enables a bunch of even higher value business services in the future. Things that directly expand their capabilities they can offer to their customers (which will be many of my readers) and do other related sexy things core to the business. The business salivate over it. It buffs their shine. They want it.

The other project is a little less flashy. The product is a rather niche product but it’s purpose is around the environmental effects of carbon emissions so at it’s core is the mission “save the planet from CO2″ — a pretty high value mission you’d think. However the actual functions of the software product are fairly mundane – based around helping large organisations capture and control data about their carbon emissions, because many of them have been required now to report these numbers to government agencies for a number of years. It has customers, all of then big companies or government agencies, and all the future prospects are similar sorts of organisations.

Which one is which? Which one uses REST/Agile, and which one is the SOA/Waterfall project? Do you think you can guess?

Would you be surprised if I said that the “sexy” transport project is the first one (SOA/Waterfall) and the second one is the REST/Agile project?

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.

So you improve fulfillment (improved quality) and customer service (reduced cycle time). Revenue increases. Try proving your improvements were the cause.

You can’t. You can’t even measure customer satisfaction accurately, let alone demonstrate its relationship to increased revenue.

Which is why those who “run a company by the numbers” so often rely on mindless cost-cutting: They can easily prove the connection to this-year bottom-line improvements, while those who complain about the long-term consequential damage have no proof — only their knowledge of and confidence in the business model.

Managing to the numbers | Bob Lewis @ Keep The Joint Running.