Having recently read the great essay Software Is Hard (via Bill) a quote in a recent story of a robot cannon killing 9 and wounding 14 South African soldiers caught my eye:
Other reports have suggested a computer error might have been to blame. Defence pundit Helmoed-RÃ¶mer Heitman told the Weekend Argus that if â€œthe cause lay in computer error, the reason for the tragedy might never be found.“
Now I’m amazed and surprised by this. Even if he is incorrect and it was a hardware failure one would have thought that a device like this would have a solid state audit trail and code log of its actions that could be used to retrospectively identify the hardware/software fault. If not, you have to wonder who is designing the software and audit/control interfaces for these guns. They can, after all fire 500 rounds/min (per barrel)
The human cost of this tragedy was high. An example of how complex software interfaces can end up costing a company billions is the recent Airbus A380 PLM disaster. In this case software incompatibilities between different versions of the Catia CAD software used by the various Airbus teams resulted in wiring bundles, totaling 300 miles in length, that were too short to fit the dimensions of the plane. The end result was a two year delay to the release of the A380, costing Airbus billions in lost revenue.
There you go, something to keep you all on your toes for Friday afternoon. Remember, never commit anything on a Friday afternoon unless you are working on Saturday!
Oh, has anyone out there actually read Dreaming In Code? Just wondering if it’s worth the purchase…
airbus, guns, hardware, software
I need to clear out the attic as our spare room is being converted into a part-time home office. It’s an annual cycle, I throw out/donate stuff and move other stuff from the spare room into the attic. So Paul Graham’s Stuff really did resonate – in fact I know it’ll resonate with anyone living in a small unit (anything built in an Irish town or city in the past ten years). I like his point that people will take services over goods any day. Perhaps thats why the product based software business is dying a death.
I really don’t think I have much stuff! Maybe I have lots of small stuff, I dunno…
services, software, stuff
Not as crazy as it sounds, but when you are designing something new, you sometimes can do worse than start by working backwards. Werner Vogels recently wrote how Amazon use this process to help their small teams produce services that customers (internal or external) want:
The product definition process works backwards in the following way: we start by writing the documents we’ll need at launch (the press release and the faq) and then work towards documents that are closer to the implementation.
The Working Backwards product definition process is all about is fleshing out the concept and achieving clarity of thought about what we will ultimately go off and build.
Given the recent bounce back in Amazon’s commercial performance and the quality of their Amazon Web Services suite, working backwards is clearly, err, working well for them.
Update: The AWS blog has announced the beta release of yet another monster web service, the Amazon Flexible Payment Service (FPS).
dev, process, software
Dare Obasanjo has a Top Ten Signs Your Software Project is Doomed post in which he references some other great posts about The Schedule Chicken Game, Second System Syndrome and others pertinent issues.
Curiously, the word requirements doesn’t appear once in his list yet poorly defined requirements must be the most common reason why software projects fail. If you don’t have good requirements you can’t even get as far as most of these issues, or even use simple techniques like MoSCoW to avoid them.
On a related note, good to see How Projects Really Work continues to evolve, now at v2.0.
With the ever growing trend towards online applications and services, software architects need to be more aware than ever of the challenges in building platforms to host these types of applications. Successful sites in this space (Craigslist, Fickr, Salesforce etc.) all have one common problem to cope with – how do you maintain availability while dealing with exponential audience growth?
Two excellent pieces serve to proffer incredible insight into the experiences of those who have hyper-succeeded in the past:
- Inside MySpace.com, by Baseline Magazine is a great read about how MySpace scaled their architecture from zero to over 26 million user accounts, serving over 40 billion pages a month (isn’t that figure just incredible!).
- Database War Stories is a series of posts by Tim O’Reilly, interviewing folks from Second Life, Memeorandum, Craigslist and more. (The rest of the posts are linked to at the bottom of the first post.)
One common theme in many of these stories: periodically these guys are faced with the stark reality that incremental improvements to existing infrastructure will not sustain the current business model. It is testimony to the folks in charge that they trust their geeks enough to bet the company repeatedly on new architectures.
It is a high-risk world and there are many that fall by the wayside but the rewards for the brave are there for all to see.
dev, hardware, soa, software, web services, web2.0
Happy New Year to your all and a belated Happy Christmas to those I didn’t get to share festive pints with! I should be back blogging a bit more frequently now – prior to the festive break I had my head down getting the Cape Clear 7 Studio Beta release (What’s New) out the door on time so it’s been a bit quiet around here. Kudos to our team for producing such a polished beta release in such a short period of time!
So now we are in sync with the Callisto train, that opens up more than a few possibilities, some of which we are already working on. Thanks are also due to the folks at Eclipse.org, they have been great at dealing with the bugs we logged while migrating from WTP 0.7 to WTP 1.5 and through our use Eclipse, PDEBuild, TPTP, BIRT and various other pieces in our build and test harnesses. In one instance I think I can remember a patch being committed within an hour of the original bug report being received!
Onward and upward, time to catch up on what has been happing in the technology world for the past month
capeclear, eclipse, software, web services
Now that I have installed Mozilla Lightning Thunderbird can finally read all those meeting invitations (
text/calendar mime attachments) that the marketing and sales folks in work are so fond of sending from their Outlook/Exchange system. It can also read Google Calendar generated events that you receive via email.
A while back I mentioned I’d be creating a HTTP EFS plugin. I finally got around to uploading the source (licensed under EPL) and a binary build onto Cape Clear’s developer website.
Note this is only a first cut but feedback is more than welcome to email@example.com
Dion Hinchliffe‘s recent WOA/Client article went pretty close to making my head explode. Calling WOA/Client the “Pragmatic Service-Oriented Architecture”, the article contains a pretty diagram that reduces the use of web services to five key patterns that are defined in detail in another article Dion wrote for The Architecture Journal titled Patterns for High-Integrity Data Consumption and Composition:
- Frequent run-time checking of only the part of the contract you care about
- Minimal surface area dependence on Web service
- Lowest possible distance between client data representation and server representation
- Tolerant, robust, federated data modification (incomplete updates must never break the application)
- Managing multiple data sources in a maintainable way. Use MVC to knit them/update them.
How this differs from any other SOA, beyond being an incomplete subset of considerations for any enterprise architect to muse over, is very questionable. Why we need another term for this set of patterns is questionable. How these patterns qualify as pragmatic when others (such as defining an interface versioning strategy up front) are somehow not is questionable.
On a deeper level, how well-defined these patterns are is also questionable. For example, I find it difficult to reconcile the use of the MVC pattern on an enterprise architecture level. Are we supposed to define model services and view services? Where does the controller get implemented and do we have to provide view callback interfaces (for the model to update the view). Do the view services have to maintain state? Sorry, the granualarity and complexity doesn’t fit distributed services at all.
And I’m still not sure what the term Client in WOA/Client signifies. I have to agree with Sam Ruby – articles like this signify that the term SOA has entered the realm of Newspeak. WOA/Client seems to be bordering on the stuff that Dilbert cartoons are made of. It may only serve to further disconnect and confuse the very architects who are struggling to embrace existing, concrete, service oriented architecture definitions.
This just blows me away – grab Democracy from the folks at the Participatory Culture Foundation, browse the various RSS feeds and end up watching content like this or this (yes, Democracy loads torrents too). Then check out their sister site Video Bomb and if have your own content set up a Broadcast Machine or your own.
Awesome stuff, with quality free software and content like this, who needs broadcast TV?
internet, movies, music, oss, software, tv