my recent reads..

Atomic Accidents: A History of Nuclear Meltdowns and Disasters; From the Ozark Mountains to Fukushima
Power Sources and Supplies: World Class Designs
Red Storm Rising
Locked On
Analog Circuits Cookbook
The Teeth Of The Tiger
Sharpe's Gold
Without Remorse
Practical Oscillator Handbook
Red Rabbit

Sunday, May 31, 2009

Lessons in Re-branding: My Aquarium and SpeedDate's Agressive Acquisition Strategy

The My Aquarium Facebook application will soon become .. a dating app??? WTF!

At first I thought it must be a joke, or someone hacked the developer's facebook account.

But amazingly, it seems for real. SpeedDate have apparently been acquiring quite a number of Facebook applications, and My Aquarium is just one of the latest.

I don't know what on earth they are thinking though. Do they seriously expect to just buy users like this? Isn't there a fundamental demographic and motivational mismatch between users of a cute aquarium app and the dating crowd (except by pure coincidence)?

Rather than endearing people to SpeedDate, I'd expect the reaction is more like this:

Get the hell of my Facebook page. First you buy up and kill off one of my apps, then you expect me to use your totally unrelated app? Get real!

Kind of like if Microsoft came along and bought up Adobe then sent an email to all Photoshop users saying they must all upgrade to Excel. Can you imagine the consumer revolt that would cause?

I don't know anything about SpeedDate, but this behaviour just makes me want to see them fail big time. Not a good PR position to be in...

Zero Day Exploit

I picked out Rob Shein's Zero Day Exploit: Countdown to Darkness (Cyber-Fiction) at the library simply because it stuck out as an obvious "computer book" in the fiction section. I thought it had been mis-shelved and so it caught my eye.

I finished reading it because ... well, it is simply so bad as to have a kind of Ed Wood "B-movie" allure.

It is a pity, because the idea has promise: a fictionalised cyber-security thriller that can almost double as a vulnerability assessment and computer forensics text because of the detail it includes.

Unfortunately, the book would be better titled Zero Day FAIL!

In terms of the computer security technicalities, it is really light weight, making only cursory reference to just a few of the most routine security issues and tools, and describing a methodology that is far from leading practice. The author's main characters are meant to be save-the-world "white hat" geniuses, but they come across as bumbling script-kiddie amateurs. Stuck debugging a program because they mis-spelt "main"? Forgot there might be a firewall in place? Found a vulnerability on the first attempt by sending a stream of É, "because it is a character know to cause buffer overflows". Sheesh!

As a novel, I don't think I've ever read a book so in need of a good editor than this. Just about every aspect needs work or a complete re-write: character development; dialogue; story arc; climax and resolution.

And did I mention the plot? It goes from sublime to the ridiculous, and then just peters away..

Mind you, even well-known authors can fall into the "sublime to the ridiculous" plot trap. Take Eric Van Lustbader for example, writing Robert Ludlum's (TM) The Bourne Sanction. Whereas Ludlum was a true master at pulling together incredibly complex and outlandish plots while never for a moment losing the credulity of his audience, Van Lustbader always seems to miss the mark by a little. And as a reader, once you start questioning the realism of characters' behaviour and the uncanny role of coincidences, then the magic of the story is quickly extinguished and the author has lost you.

I mention The Bourne Sanction for one further reason: like Zero Day Exploit, it features terrorists attempting to distroy the petroleum distribution infrastructure of the US. And the one thing that Rob Shein should feel happy about is that his scenario for how this could be done is way more credible than what Van Lustbader cooked up for The Bourne Sanction (which made me think Van Lustbader was probably script-consulting on Speed 2 at the time)

So was Zero Day Exploit mis-shelved? You bet. They missed the bin by a mile!

Friday, May 22, 2009

Faster and Faster

'ere, guv. Got a new mota?

More at Andy J Gallagher. Great Brit-indie-pub-rock vibe. Now listening to his Crocodiles & Prostitutes EP...

Sunday, May 17, 2009

The Software Architect's Professsion

That was a happy age, before the days of architects, before the days of builders. -- Seneca c.4BC-65AD

I hesitated as I reached for The Software Architect's Profession: An Introduction (Software Architecture Series) on the library shelf.

Did I really want to read another treatise on the role of the software architect? Hasn't the term architect been so abused as to now be worthless, even downright counter-productive? In this, I think I am one with Jeff Atwood and Joel Spolsky who discussed the questionable value of the title "Software Architect" on StackOverflow podcast #44.

Nevertheless, my hand followed through. I think I was persuaded by the unimposing nature of this concise little 100-page book.

I was pleasantly surprised; this is a great little book for stimulating some thinking around the role of an architect for the advanced reader. But I worry that it attempts to position itself as "An Introduction". A novice, unprepared to read the text critically, may easily be mislead by the book's definitive statements about what a software architect is and what they do.

Personally, I believe the book is fundamentally flawed in three important aspects:

1. Are we really in Crisis because we lack a Software Architecture Profession?

Firstly, the premise that today's Crisis in Software...
[the] parade of failures and half-failures that has grown over the years as a result of a world without an established profession of software architecture wholly unsupported by any direct evidence. The authors' central argument is of course flawed based on the appearance of a causal relationship where in fact only coincidence has been established beyond doubt. A number of well-known software runaways and failures are mentioned, but I don't know of any where the original case studies attributed the failure primarily to the lack of "an established profession of software architecture". The authors get around this problem by redefining the conclusions and suggesting that all faults may eventually be explained by architecture. It seems to me self-serving and circular.

2. A Flawed Analogy with Building Construction

Second, the authors attempt to reinforce their argument with the proposition that the analogy with building architecture is self-evident. Buildings need architects. Software is like building. Therefore software needs architects. Hmmm. I am reminded of Bernard Rudofsky's book "The Prodigious Builders" which celebrates the history of vernacular architecture. That is, architecture without Architects (unfortunately a stunningly boring book for what ought to be a highly inspirational subject).

I particularly disagree with the authors' contention that software is not developed: it is built (with a sense of finality). The Google-inspired trend towards the perpetual beta is the most visible evidence to the contrary. The authors object to the notion that to develop implies to unfold, uncover, and make known. On the contrary, I find this a most apt description of what we do within the software profession: the youth and continuing innovation within the field does mean that software development and the architecture it requires is more akin to exploration, invention and discovery than to a formalised application of the tried and true.

Strike two.

3. Premature Specialisation

I began to renew my hope for the book as it explored the historical foundations of architecture. Michelangelo can truly lay claim to the title of Architect ("master builder"); his work on St Peter's Basilica epitomizes the unltimate balance between function, beauty, and structure,

Vitruvius is famous for asserting in his book De architectura circa 50BC that a structure must exhibit the three qualities of firmitas, utilitas, venustas — that is, it must be strong or durable, useful, and beautiful. A sense of proportion and harmony is represented in Leonardo Da Vinci's famous illustration of Vitruvian Man.

Such ideas begin to shape the conventional definition of an architect. A master who not only understands structure, utility, and beauty in order to successfully render a design into plans, but has the practical experience to supervise their realisation through construction.

At this point, I think the authors are getting onto the right track. However they stumble at the last post by then inexplicably turning this into an argument for a limited and specialised concept of a "Software Architecture Profession", where the architect only retains responsibility for venustas (design/beauty). Utilitas (function/utility) is the client's problem, and firmitas (form, materials, logistics) is the province of the engineers, scientists and code monkeys.

Time for the Renaissance?

The authors' call for the codification and ossification of a software architecture practice is I think at least 50 years premature.

What an "Architect" needs to be concerned with is still going through successive waves of tumultuous change. Up to the green-screen era, computer system architecture necessarily had a strong hardware component. Come the GUIs and increasing processing power in the 90s, it seemed a singular focus on "software architecture" as a technical discipline was a valid vocation. Now the waves of web-driven innovation and the emergence of the "Rich Internet Application" is again challenging our notions of what architecture entails. And again, the "real world" is encroaching the pure software realm with the rise of increasingly powerful and widely available mobile computing platforms (think iPhone, Android), and the revolution in pervasive automation (think Arduino).

I think the Java Posse were spot on when they discussed the growing need for cross-fertilisation and collaboration between designers and developers on podcast #247 - Design and Engineering. This is a time of divergence, not convergence, in the business of producing software & technology-based systems.

In truth, I question how appropriate both words are in the term "Software Architect":
  • Software - it is perhaps only in the last 10-20 years that it has been possible to construct computer software at the level of complexity that warrants the existence of an architect in the classical sense. And I suspect that in another 10 years it will seem ludicrous to suggest that you can be an Architect of only software ("just a turn-of-the-century fad"). Software is just one component of a "built environment" that encompasses everything from the information infrastructure and systems technology to the psychology, art and design of human interaction; ultimately leading to a desired collaboration between people and machines in the context of real-world objectives.
  • Architect - the common use of the term in the computing field has stripped this word of it's more noble dimensions. No longer is the architect "the person with the vision and skill to make dreams a reality". They are more likely to be the person in the corner who produces nothing but paper, leaves no fingerprints on the pages of history, and is generally ignored by those who are really making things happen.

I don't know what you should call the people who have the experience and ability to lead others to do amazing things with the information technology we have at our disposal.

I'm just pretty sure that "Software Architect" doesn't even come close to being adequate. And building a "profession" around a woefully inadequate definition is a one-way ticket to irrelevance and obscurity.