let x=x » design

High-performance system design by declarative specification

Scot Mcphee — Mon, 28 Nov 2011 02:04:51 +0000

“I want to get from London to New York in 12 minutes.”

“Ok, we will have to design and build some sort of ICBM or buy one, that will cost a lot of money. Also, I’m not even sure you can get an ICBM that’s fast enough for that distance. And have we thought about acquiring land for the launch site or what sort of launch system will we considering?.”

“But I want to do it in my car.”

“Oh, well, that’s a big ICBM, to hurtle that sort of load in that sort of timeframe across that sort of distance. Molto-dinero. Also, re-entry procedures at the New York end could be tricky and …”

“No, I meant, I want my car to be used for the journey.”

“But that’s not possible!”

“What sort of engineer are you? Can’t you just soup it up a little?”

“Well even if we could make your car amphibious, there’s no way it can travel 5,500 kilometres in 12 minutes”

“I don’t want an amphibious car!”

“Have you considered a ship of some type?”

“Yes a ship will get me and my car to New York.”

“Excellent. It takes about a week for a ship to cross the Atlantic I believe.”

“But I just said in my specification that it has to take 12 minutes! Also I wish to travel via the Pacific Ocean, as it is prettier this time of year.”

” … !!! “

The Frustrated Architect

Scot Mcphee — Wed, 16 Nov 2011 11:48:34 +0000

An interesting set of slides by Simon Brown from a talk he gave about the role of the architect. A PDF is attached to the linked post or you can view the slides online. ~~Wish I had heard the talk~~ (see below).

The Frustrated Architect:

Software architecture plays a pivotal role in the delivery of successful software yet it’s frustratingly neglected by many teams. Whether performed by one person or shared amongst the team, the architecture role exists on even the most agile of teams yet the balance of up front and evolutionary thinking often reflects aspiration rather than reality.

(Via coding the architecture.)

Update – if you go to this page you can get a video of the presentation; it’s about an hour long. A word of warning: I couldn’t make the video play on the site with Chrome, I had to use Safari.

That feature is trivial

Scot Mcphee — Fri, 31 Jul 2009 07:00:09 +0000

How many times as a developer do we get asked by our clients to create a new story to implement a feature assessed by the client as “trivial”? How many times do we get surprised by their reactions when we give them our story estimate. I’ve seen developers give this sort of optimistic estimate too, without considering all the wrinkles, like error handling, alternative usage scenarios, abusive usage & security concerns, and all sorts of other issues that can be way bigger than the “happy-path” through the code. Here’s a neat little article from Brent Simmons that summarises the sort of user experience and technical design that has to go into the “Oh, it’s easy” feature.

inessential.com: Anatomy of a feature.