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...

Tuesday, May 26, 2009

Hyperwords - fact-checking the web at a glance

Two things I find myself doing oh so frequently when on the net:

  1. Getting referred to wikipedia after googling

  2. Checking word spellings and definitions with one of the online dictionaries

With the Firefox add-on Hyperwords, both these activities just got incredibly easier. Just select text in your browser and you have instant access to the related wikipedia entry, check the dictionary and more (stock quote lookups etc).

Even better, the results pop-up in the browser so you are not left with a cascade of windows or tabs to get lost in.

It joins firebug as one of the top two "must-have" add-ons for my Firefox install!



Hat tip to blankanvas for putting me onto this..

Saturday, May 23, 2009

TDD and BDD is old school. Make the jump to HDD (Humour Driven Development)

SlashWeb just posted their list of the 25 Best Programmer Comics. I wonder ... seems like it could have been inspired by the stackoverflow question What’s your favorite "programmer" cartoon?.

xkcd's Proper User Policy apparently means Simon Says (sudo make me a sandwich) comes #1 in the SlashWeb list, versus the stackoverflow community voting xkcd's Little Bobby Tables to #1.

Conclusion? Either way, xkcd rocks.

But how's this for cool: xkcd's "antigravity with python" actually made it in as a patch to the python source code!

Sunday, May 17, 2009

The Software Architect's Professsion. Or Delusion?


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

- is wholly unsupported by any direct evidence. The authors' central argument is flawed by asserting an apparent causal relationship when in fact only coincidence had 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.