chris mountford

Apple: I Was Wrong, Here's Your $200 Back

2010-07-05T21:03:00.000+10:00

Previously on Chris Mountford's blog...

Genius: "Oh um ya that battery that split open like a stepped-on-banana.. that's expected behaviour"
Me: "You're kidding me? Should I expecting all other Apple products to do this?

The latest is, thanks to Mr Anonymous, Paul M and legion others like them, is that I have been refunded my $200 because, as a reasonable person would assume, the extended warranty DOES cover such explosive situations.

Exploding Macbook Pro Battery = "Expected Behaviour"

2010-06-28T21:30:00.000+10:00

After booking my appointment with a Genius at the Genius Bar in Sydney's city Apple Store, waiting in line dutifully holding my AppleCare extended warranty stuff, packing what I thought would be an iron-clad case of Exploding Battery Obviously Defective Here's A New One Sir, I was rudely awoken by the facts.

Apple's official position, according to the lips of two courteous Genii, is that exploding is "expected behaviour". The battery was bought with the computer in June 2008 (exactly 2 years ago) and it had been sitting for a couple of months looking like this before I got around to taking it in:

Well it's not behaviour I ever expected. And I say this with some experience with batteries, even lithium ion rechargeable batteries, that ranges roughly two fashionable Genius lifespans or near enough, judging by their fresh-faced appearance. I've never had anything like this.

I think the elephant in the room is that while the fine print may say that the extended warranty doesn't cover batteries, this is a major manufacturing defect and Apple know it. I was virtually told as much as I was assured my 1 year old Macbook Pro with the built-in battery would not suffer the same fate since it is a non-nickel based lithium polymer construction. I was invited to attend the Apple battery page: http://www.apple.com/batteries/ which keen observers will note contains nothing of Apple's expectation of explosions.

Looking further the Apple battery replacement page says:

However the AppleCare Protection Plan for notebook computers does not cover batteries that have failed or are exhibiting diminished capacity except when the failure or diminished capacity is the result of a manufacturing defect.

Right so, who says this is not a manufacturing defect? Shouldn't a manufacturer's expectations about common failure cases be published on thier main information page? If it really is not a manufacturing defect where is the information about this expected behaviour on their written material?

The battery still holds a charge as demonstrated by the indicator lights on the battery. Also, although it doesn't properly fit the case due to it's unsightly bulge, it was powering the laptop fine until I took it out. In fact the reason I did so was because the bulge was pushing the back of the mouse button, preventing it from clicking. None of this stuff appeared to be news to the Geniuses. Just another exploding battery.

So $199 later, I purchase a new battery which, I carefully confirmed, would be expected to explode in roughly 300 power cycles (which I assured the young Genius my existing battery had not experienced).

Has anyone else had luck in getting their battery replaced as a part of Apple extended warranty? I see plenty of talk to this end:

http://www.appledefects.com/?cat=27
http://discussions.apple.com/thread.jspa?threadID=909217
http://www.tuaw.com/2006/12/25/battle-of-the-battery-bulge/

Aussie Censorship Error

2010-03-16T16:23:00.003+11:00

As a father of three young kids the thought of child porn disgusts me.

If only an Internet filter imposed by the government would be effective against it.

As a professional software engineer I can't help but acknowledge that the proposed filter will be 100% ineffective at stopping child pornography and that hundreds of millions of dollars could be better spent elsewhere.

The proposed censorship by senator Steven Conroy does not propose to stop most material that is unsuitable for children and it does not propose to stop the most common channels of illegal content on the Internet (bit torrents).

Finally any VPN will effectively go straight through the filter so anyone who wishes to can circumvent it using current technology.

Titanium Reinforced Self

2010-03-15T22:33:00.003+11:00

For those of you I know personally, you've probably already seen my impressive X-rays, but for the rest of you I'm announcing that I have recently had cause to become hyper human.

Not content with collar bones constructed of mere bone matter, which I ably demonstrated can break with the aid of a single mountain bike and a spot of bad luck, I opted for hyper human augmentation.

I can wholeheartedly recommend the procedure should you be advised that it's necessary for adequate bone knitting. It completely stopped the disconcerting clunk that occurred in my shoulder on certain movements for the 36 hours prior to surgery.

The only down side was, apart from the usual recovery and healing process, I discovered much to my surprise, morphine is quite disgusting. It certainly blankets almost all pain but at the expense of almost all cognitive ability.

Further, morphine causes the sensation of hanging upside down in a vat of warm butter after having skulled a salmon milkshake. With an automated IV drip, that feeling was only a button press away should I become convinced that it was better than post op pain.

Now I'm back on the bike but my shoulder does not have 100% strength or mobility and my muscles feel wasted and weak all over. So if you happen to pass me on a hill, this is going to be my standing excuse.

More Cowbell in One Line of Groovy

2010-03-09T14:12:00.003+11:00

Sometimes you just need more cowbell.

It is for those times that I wrote this:

groovy -e 's=javax.sound.midi.MidiSystem.synthesizer;s.open();c=s.channels[9];c.noteOn 56,99;Thread.sleep 99;c.noteOff 96;s.close()'

I do often find myself needing more cowbell, such as when invoking a maven comannd which inevitably downloads the internet, like mvn clean. So get this puppy on your PATH and you can do this:

mvn clean && cowbell

...for an audio cue that tells you the internet has been successfully downloaded with a modicum of funk.

Ali G Joins Github Team

2010-02-20T20:11:00.003+11:00

I was browsing a Github hosted project, Mangos recently and attempted to check out the network graph visualisation of the clones of this open source World of Warcraft server.

Moments later I learned that there are too many branches on the graph for the flash visualisation to render. The following error message is shown:

Sorry, this repository's graph is currently too logical awesome to display. We're working on optimizing it. Check back soon.

Which leaves one wondering just how much is the right amount of logical awesome.

Clearly the only conclusion is that the Github team has been joined by a celebrity error message writer, Ali G:

Booyakasha!

A Tale of Three Buzzes

2010-02-11T11:47:00.004+11:00

Google's Buzz is causing a stink. It's the third social network which is called "Buzz" to come out recently. All have the Twitter model of microblogging (or multicast chat) with an asymmetric social graph (people decide who they follow but not who follows them).

Yahoo Buzz has been out for at least a year on buzz.yahoo.com and predicatably, Yahoo and their new overlords Microsoft are going batshit insane about this.

Oh really Microsoft? You've got a product and a bigger competitor comes along and uses your idea? And they use the generic term to name it? That must be annoying. The worm has turned.

And the drones at AT&T launched buzz.com about 6 months ago. Less said about that the better. In fact you can probably safely forget them right now.

So now we'll all be looking forward to the shakedown. There are too many players.

I think the winner will be the service that provides enough features (not necessarily the most, Facebook) with the best integration with everything else. Twitter so far has been successful at crowdsourcing the integration work with the massive proliferation of Twitter clients and "tweet this" buttons like Tweetmeme. Can Yahoo/Microsoft get this traction?

Google already has a great integration story. When the hundreds of millions of monthly GMail users hit their inbox now, they will be able to thread together lots of their google software that produces socialisable events. Now the google suite can buzz.

Perhaps it's just me but the one image I have about Buzz is those hotted up cars with the ultra-loud stereo systems and the monsterous bass frequencies causing every bolt in the chassis to loosen and the number plate to buzz.

China Hackers Update: Arrests and Details

2010-02-09T22:47:00.006+11:00

It is inevitable after the Google hacks, as they are known, that China responds by showing its international business partners that they do not condone hacking.

China Daily reports that the biggest hacker training site has been shut down. via RWW

"I could download trojan programs from the site which allowed me to control other people's computers. I did this just for fun but I also know that many other members could make a fortune by attacking other people's accounts," said a 23-year-old member of Black Hawk Safety Net in Nanjing of East China's Jiangsu province, who asked to remain anonymous.

and

They seized nine Web servers, five computers and one car, and shut down all the sites involved in the case, according to the provincial public security department.

So there you go Google - nothing to worry about. The "provincial public security department" got the baddies. Carry on.

Of course there's no reported link with what is now clearly a much larger and more sophisticated program of industrial espionage than previously thought as reported in detail by wired magazine.

The salient points of the wired article are:

The hacks have compromised thousands of companies, not just 37 as previously reported.
Most of the compromises are currently still active and law enforcement has been contacting companies to let them know they have been compromised.
The exploit was an IE 6 security flaw that was first reported to Microsoft by an Israeli researcher in September 2009 but which remained unpatched for months. ("0-day")
The attack profile include multiple-year-long occupation of companies' computer systems and typically involved hidden siphoning of large amounts of private data including email, documents, etc. This is in contrast to the smash and grab techniques more common in the past.
Existing security software (like antivirus software) is not able to detect this attack profile or the malware used to initiate it.
The full extent of data theft will never be known.
The goal of the attacks appears to be coroporate and national espionage.
The hackers have levelled up.
The trail goes dead in Taiwan where the data was siphoned to and China where the spear phishing attacks were initiated from.

Now it really feels like we're living in a Neal Stephenson novel.

Build to Flip vs Organic Growth

2009-12-10T20:36:00.004+11:00

In this world of GFC hell (is it over yet?) the biz buzz is "Organic Growth". That is to say business owners who are looking forward to the challenge of entrepreneurship in a downturn are standing as proud adovocates for a refreshing change to the mentality of the bubble and the zero profit, high valuation world of two point oh dot coms.

It's refreshing because the business press is usually obsessed with the crazy valuations. A sale price with more zeros means more heroes. Examples abound. Twitter's recent funding round reportedly topped $100,000,000. That would be nine zeros. Profit is currently just zero. You'd think by now they could afford to give us more than 140 characters.

Clearly people building businesses the traditional way, you know, charging a price (stay with me) for a product or service and growing revenues slowly over years, those people feel some justification in presenting themselves as a sane alternative to a world gone mad. Atlassian CEO Mike Cannon-Brookes has ranted exactly this in the past.

With financial systems in the toilet due to excessive valuation of flaky assets, this can seem justified as much as ever. Indeed my own aspirations for a new business incorporate this sane model of organic growth. I know it could take longer.

It seems that the venture capital (VC) funded model of startups popular in silicon valley are stuck in railway thinking. VCs think that if it isn't something they can put many millions in and get hundreds of millions out, it's "not interesting". And of course more is always more.

As a tech guy, I think the prospect of growing a business up from nothing seems plenty interesting. But if I had taken millions of someone else's money to start the company, well the reality is I'd have already sold the company. A chunk of it. I'd have borrowed money and would need to pay it back. How would I pay back the millions with extra zeroes on the end? I would have to sell out big. This is the railway. Once you get on it you don't get to choose where to go. You only get to choose when to get off, assuming you don't run out of steam. And VCs don't want you crawling down the track. They are looking ahead to their exit impatiently. They want their money to fuel the train as fast as possible. Destination "liquidity event".

On the other hand, is it really a problem if people want to start a business with someone else's money and sell it in a couple of years? What's wrong with build to flip?

I think the real problem here is cultural. If kids these days aspire to be like Kevin Rose, founder of Digg, or want to build the next Facebook or Twitter or even Mint (just bought by competitor Quicken for $170M), they may well be building with a mind to sell out in the short term. I don't think this short term thinking will build the next generation of great companies. It wasn't the kind of thinking that built Apple or Microsoft or even Google. These companies have really made their mark and changed the world, hopefully for better, but they're clearly more than an expensive flash in the pan. Even Bill Gates has become quite the philanthropist.

The parallels of build to flip with the the Underpants Gnomes are too stark to ignore. Can't remember step two.. never you mind about step two. Step three is profit. I suspect it's only this pesky string of recent bank collapses that has put a dampener on the craze of Underpants Gnomes business models. If the GFC hadn't happened first I think the startup upstarts might well all have bubble gum on their faces by now.

Jason Fried on Less is More

2009-11-17T11:28:00.003+11:00

I'm a fan of Jason Fried, the 37 Signals founder who sticks to his guns and stands up for simplicity in software design. I like how he's a dissenting voice and clearly has the courage of his convictions. I like how he promotes what VCs disparagingly call "lifestyle businesses". I'm happy that he's been featured on INC, a major US business magazine, even though I'm not enough of a fan to care what kind of tea he drinks and all that.

I'm a fan of Less is More. This year I have been exploring the surprising depth and complexity of this oft-quoted pithy aphorism. Jason Fried is a Less is More poster boy. Except he doesn't like the phrase. I've read it from him elsewhere, but the INC magazine feature reminded me.

If he didn't like less is more because it was overused and therefore overlooked, I would completely understand. But that's not his objection. He says that he doesn't like Less is More because it implies that More is better. Ridiculous!

Actually I worked with a guy who straight-out didn't understand the phrase. In one of his customary rants about inconsequential stuff he confided that he thought Less is More was vacuous and clearly irrational. "More is more and less is less!" he said.

First of all, I think it's obvious why it has a deliberate and prominent paradox. The semantic collision is a key feature of its beauty. Less is More works so well because it identifies the conflict of competing values in a compact and humourous way.

Less [of one thing] is more [of another].

There is an unspoken contex shift in the middle.

So to object to the phrase because it implies that More is better is to misunderstand it on the most flimsy semantic level. Less is better because it is "more good". To advocate Less you must refer to its superiority. Inherent in every word to describe "better" is the notion of "more". It's just words!

So to properly appreciate how well Less is More applies to Jason Fried's own philosophy of software design, you see that (arguably) less features enables something. Something is gained in their place. There is more of something.

Understanding what the two sides of the see-saw are is the critical (dare I say pivotal?) task of applying the less is more wisdom to a given situation. What exactly is the tradeoff being made? This is how I use Less is More in my software development and also in my life.

The opportune moments for the wisdom of Less is More are more specific than just identifying competing goals. It represents minimalism. It's not just less pizza is more beer. It advocates a fresh look at what is essential and rejects overconsumption, overburdening, hoarding and powermongering. It represents a philosophy of happiness and a wholistic goal rather than the pointless pursuit of intermediate tokens that we first world people frequently use as proxies for real goals.

Less is more is a tool for escaping from the distraction of things that are merely a means to an end and resets attention on the end itself.

There are usually hidden tradeoffs in software design and the business of programming. The 80/20 rule (the Pareto Principle) is essentially a variant of this where the see-saw becomes a lever and therefore provides (hold your nose) leverage.

Complexity is befuddling. Complexity in software actually prevents people from getting their work done and often inhibits progress towards their goal. For all it's enabling potential, complex software has an opportunity cost. When I was a kid, I had the justified belief that I could learn any application in one sitting. Those days are long gone. There's a great power to that. Jason Fried seems to be a voice in support of this idea.

I'd like to write more on Less is More. I think the irony is stopping me for now.

Smart Programmers Who Don't Get Patterns

2009-10-06T22:32:00.004+11:00

I've been recently struck by the relatively large amount of ignorance about software design patterns amongst the pundits and seemingly intelligent "thought leaders" of the sofware development blogosphere. Actually it's not all that recent.

Sure, I expect newbies and unscreened job applicants to fail to understand the point of design patterns, but to me they've always been one of the things all good developers should understand.

First, I don't think the problem is the definition. I'm not squabbling about this. People get this mostly right. A design pattern is a form of solution to a known problem. They originate from Christopher Alexander's work in Architecture where examples include the "Ante Room" or "Roof Garden". The idea is that a pattern describes a general solution to an open range of problems. Architects might consider adding a "Roof Garden" when they are faced with forces and constraints in a design project where the Roof Garden can help achieve the design goals.

Thanks to the work of many OO pioneers, but most famously the Gang of Four via their seminal book, Design Patterns, the software world has adopted design patterns as a technique for storing and disseminating software design wisdom.

But why?

This is where many otherwise well-trained and intelligent software developers fall down. They think that the point of design patterns is component reuse. They think that, like building blocks, design patterns are prefab parts you can stick together, thereby doing less work or using less attention. And once this mistake is made, their rejection of this dumbing down of attentive design in place of convenience is understandable.

But they have missed the point.

The whole point of design patterns is to enable communication about design. Design patterns are an attempt to standardise a vocabulary for solutions. Design is frequently a collaborative effort, and even when it's not, a design concept often needs to be communicated either verbally or in written form. Learning about system design also relies on a standardised language.

So a design pattern usually has a kind of specification which includes a stable name and possible aliases, description and suitable use situations. Developers who have used this pattern can then use the name instead of some long-winded boxes-and-lines session at the whiteboard.

Now for some examples of seemingly intelligent and experienced software developers speaking out against design patterns.

Some years ago Paul Graham and others argued that Design Patterns suggested a violation of the DRY principle and that they always indicated a smell that the program required refactoring to remove duplication or that the language was not powerful enough to factor out the duplication. While this could in theory be true, only Lisp developers are in danger of suggesting that their language is perfect, so for the rest of us (statistically speaking, everyone), perhaps there is enough complexity and subtlety in our domain that we find ourselves able to recognise solution forms that we can name and talk about, and yet not implement generically.

I take his point, but I think for most people it's a principled rather than a very practical one. The reality is that we live with imperfections in everything, so even if design patterns only exist to cope with this imperfection, then they will still have a seemingly permanent role.

The point that different languages have different patterns, some more than others, is well documented, and really orthogonal to the issue at hand - namely that design patterns are useful primarily for collaboration and communication. Even programming language designers use design patterns. All (impefect) programming languages, like all software, are knowingly designed to contain a subset of all possible features. Don't forget simplicity is a very valuable feature. Apparently Ralph Johnson, one of the Gang of Four, pointing this out did little to calm the hysteria on an argument that design patterns formed a list of language features that should be implemented.

Zed Shaw, Ruby on Rails agitator and apparent chronic self-congratulator warns developers in his keynote entitled "Why Keynotes Suck" which was (with what one must assume is deliberate irony) literally read off an irc channel:

"Stop using patterns. No really, quit using patterns, they aren't helping. I have evidence on that by the way, which is later"

I didn't catch the evidence but later he did say:

"Adapter, Bridge and Connector are the same"

And then

"Patterns suck, use algorithms."

The idea of patterns "not helping" conjures images of these dead zones in the code where there is a pattern just taking up space and not actually providing functionality. Should I go and delete all the patterns from my code? What would pattern-free code look like? Do they just suck because there are aliases? Plenty of algorithms have multiple names. What makes algorithms ok? Is Zed just trying to sound old school?

To be fair, during this talk his main point was to encourage individual thinking and not to follow advice blindly (including his own) but I do get the impression that his idea of patterns has come from the blind cookie-cutter adoption of patterns with small amounts of bad glue code holding the "architecture" together. We've all seen it.

A recent example is from a video interview with Stuart Halloway author of "Programming Clojure" and a series of articles about post-java jvm languages. When explaining the advantages of macros, Stuart basically repeats Paul Graham, saying,

"Languages that have macros don't really have design patterns".

Perhaps because he thinks a design pattern is when:

"I couldn't really figure out how to solve this in a resuable way, so whenever I hit this problem I copy and paste from somewhere else and tweak. So it's amazing that design patterns has put a positive spin on this copy and paste reuse of these blocks of code".

I'm not an expert on functional languages with macros, but Peter Norvig is. Even this mighty Lisp and AI guru identifies design patterns in such languages though he does say that 16 of 23 patterns are either invisible or simpler due to language features like macros, first class functions and multimethods. Stuart may be overstating it - I think what he is talking about is a more populist use of the canonical GOF design patterns and similar OO patterns.

The dread curse of this misunderstanding about patterns seems to have arisen from the usual cause of all technology's ills: marketing. I distinctly recall a Compuware salesman give a bone dry presentation to a local Java user group in about 2000 demonstrating how you could avoid programming almost completely by dragging and dropping patterns from a palette onto a ... thing on the screen. Clearly not targeted to a group of programmers so geeky that they want to get together after hours and talk about the joys of programming. Similarly books about something called "pattern oriented architecture" began to appear and patterns was something to put on the resume.

What these people need to understand is that design patterns will continue to be useful and to have a role because they are one level of abstraction above implementation. They are needed to explain solutions in terms of a programming language but they cannot be replaced by the language. They are softer than software.

My Code Sux!

2009-08-27T10:12:00.002+10:00

I don't know about you, but when I look at code I wrote three years ago, I always seem to think it sux.

And that's a good thing.

If the code you wrote three years ago doesn't suck then you're not learning.

Incompetence is the Most Powerful Force in Software Development

2009-05-27T10:21:00.004+10:00

Incompetence is the most powerful force in software development. It's like dark matter. It makes up the vast majority of the observable software development universe but nobody has discovered how to harness its power - for either fun or profit. This doesn't stop people constantly trying.

In the many software development shops I admire, it is universally avoided. For example, at Atlassian, we concentrate on how to profit from software development using the best people we can find. I think we're resigned to the intractability of utilising incompetence.

For some, however, the allure of the ready availability of incompetence is too much to resist, and besides, it accumulates like lint or administratium. Only the good people leave. So why not harness the immense power of this abundant natural resource? Unfortunately incompetence is a force that can only be used for evil.

To a businessperson, incompetence is such an "obvious" business potential. It's tantamount to turning lead into gold. There is a desperation in business to believe that it can work and that there isn't some inherent value missing from that raw material. The rule applies for all skilled specialists, especially of newfangled, esoteric or otherwise incomprehensible arts.

In software development there's a long legacy of tools vendors preying on this desperation as they sell software that purports to make it possible for muppets to perform like competent professionals. No clue required. I have some future posts lined up on this topic, so stay tuned for some bile.

This post continues my apparent pattern of physics metaphors for software development:

The Laptop Law of Relativity
Quantum Mechanics and Unit Testing
When a Team Gels: a Motorcycle Powerband

So unless you've worked out how to turn lead into gold, avoid it or risk it all. Everyone knows, like a misconfigured hadron collider, incompetence can cause your project's universe to implode.

When A Team Gels: A Motorcycle Powerband

2009-05-14T21:09:00.004+10:00

When a team gels, there's nothing like it. Explaining it does no use - it only sounds like a cliche or bad sports metaphor. But there's no mistaking the sensation you get. Not to mention the hyper productivity.

What it reminds me of most - me with my "overactive imagination" as Mr Ryan, my 4th grade teacher would say - ahem - what it reminds me of most is hitting the powerband on a motorcycle. Bear with me! I can bring this baby in to land.

Now this, I think I can explain. When you open up the throttle on a decent motorbike, the engine goes faster and obviously the bike accelerates. But (depending on lots of engine-type stuff) there can often be a point in the speed of the engine where several things come together at once, and you learn that once the revs reach a familiar resonance through the body of the bike, what was an ineffectual buzz only a moment ago transforms into a surge of forward force that teleports you down the road - wherever you point the thing - at a whole new category of fast. Instinctively you pull against this force as it threatens to rip your arms off and you become one with the machine, the front wheel unweighting and your face an immutable smile. It's like magic, but of course, it's just physics.

This gratuitous metaphor got me thinking about the "physics" of a team gelling and what factors contribute to it. Then I realised the metaphor goes even further.

In a team, the sensation of things starting to "gel" is a categorical transition. Team members anticipate each other's needs, they are able to judge the relative priority of each others goals and they can correct the natural misunderstandings that happen in all communication with greater speed and less fuss. The communication, the routines, the knowlege each member has of the others, it all starts working together.

I'm not going to put my amateur psychologist hat on (you know I've got one), but it struck me that this feature of the interactions between team members is very like a fluid dynamics scenario. It's complex and chaotic and all that, but under certain conditions, all the ins and outs and vortices and what not stop working against each other and find a kind of harmony.

Well guess what? That fluid dynamics scenario is literally what's happening in the engine as the motorcycle hits the power band. The timing of the fuel and air flowing into the engine, the combustion rates, temperature and pressure changes, exhaust speed, the lengths and volumes and shapes of each part of the whole breathing system work together more and against each other less.

So if you've never worked in a team that gelled (believe me you'll know if you have) then keep working towards it. Either that or get yourself a motorbike.

Brief, Incomplete, Wrong, Funny

2009-05-11T15:02:00.002+10:00

Just spotted a pants-wettingly funny satirical history of computer programming languages over at James Iry's blog, One Div Zero, A Brief, Incomplete, and Mostly Wrong History of Programming Languages.

Here's a taste:

[Lisp] remains an influential language in "key algorithmic techniques such as recursion and condescension"

and

Lambdas are relegated to relative obscurity until Java makes them popular by not having them.

and it all started back in 1801:

1801 - Joseph Marie Jacquard uses punch cards to instruct a loom to weave "hello, world" into a tapestry. Redditers of the time are not impressed due to the lack of tail call recursion, concurrency, or proper capitalization.

Whereupon one wit proclaimed in the comments:

Jacquard's loom wasn't concurrent? It was pretty thoroughly multithreaded, I'd have thought!

Programming languages are furtile ground for satirical humour. Like the awesome Programming Language Designer or Serial Killer quiz and the ever growing mound of esoteric programming languages such as Brainfuck, Befunge and INTERCAL.

Being Clever

2009-04-30T14:48:00.000+10:00

In software engineering, being clever is not smart.

Google What's Up CAPTCHA

2009-04-21T19:42:00.004+10:00

I heard about the new Google robot detector a.k.a. CAPTCHA from a security blog I've been reading, ha.ckers.org.

The captcha problem is a real favourite of mine and I think about it all the time.

Good old "rsnake" seems to dismiss this new system seemingly out of hand. I think it's great. Google's What's Up CAPTCHA makes several improvements over the previous warped letters systems. Many of these are described in their report.

Briefly, the system involves showing randomly rotated pictures and the user is prompted to indicate which way is up.

Firstly captcha is only about robot detection. It won't detect large hordes of humans paid paltry sums or coerced to pass your detector. Don't blame captcha. This is not the seven letter acronym you are looking for.

The current letter recognition strategies all require a large amount of noise or distortion to be added. It doesn't help that computer scientists have been working for decades to improve automated letter detection in the presence of noise for legitimate purposes. The reality is, as with Chess, computers have become pretty good at it. Excessive noise can throw them off, trouble is most people seem to have almost as much difficulty.

Warped letters, along with most if not all visual stimuli leave blind people in the lurch. Often a parallel audio cue is used for them.

Another problem with letters is that they are not very international. Many cultures are comparatively unfamiliar with the English alphabet which is invariably adopted for captcha and will have an even harder time than native English speakers in recognising letters after they've been twisted.

RSnake takes a hurried swipe at the new system by running through the captcha acronym coming up with the following categories of dismissal:

It leaves blind people in the lurch.
It is not Completely Automated, requiring Google staff to run through images to see if there is an obvious "up".
It requires JavaScript, Flash or other new fangled technology which people like RSnake never use.

I think he's wrong on all three counts.

Firstly, a parallel audio alternative is no less an option than it is today. Blind people can use that. It can remain a completely parallel audio captcha effort with it's own analogous problems. Perhaps people aren't writing audio captcha solvers. Perhaps it's still too hard.

Secondly it can be completely automated. The fact that humans will reliably discern "up" in pictures that have a discernable up will show up in large numbers of responses. Robots will be random, systematically wrong or inaccurate across a greater range than humans. If you present a series of prompts and use the combined results to decide then you can get whatever statistical probability you deem acceptable. The only critical factor is that humans find it easier than computers by a significant margin.

Without human intervention, you may get non-performant source images, such as a photo pointed straight down at the ground. Presumably humans will not be able to tell "up" uniformly and these can be weeded out of the source pool using only responses to the prompts.

So, assuming "up detection" is still too hard to automate, this will make a nice captcha system. If this assumption starts to be violated, then it will be time to dream up a new system.

Lastly, I can say with some confidence that this system can be implemented with no new-fangled technology or plugins. Just images and HTML. Not as "2.0" as the AJAX version, but adequate.

There are some other awesome captcha systems that I have heard of over the years. Of particular note is kitten auth and hot or not captcha where you prove you are human by identifying kittens and sexiness respectively.

My mind is bubbling with exciting ideas on this topic, so it's probably a good point to cut this post off and promise to put those to print another day.

Don't Be Quality Guy

2009-04-06T12:13:00.002+10:00

Do not make the mistake of taking on the role in your team of the greatest advocate for improving quality. Don't be quality guy.

This was the advice given to me by an ex-colleague and he assured me it was first-hand wisdom, hard-won.

My approach has been to see things as business cases. Does quality always have a business case? This is something I've been wondering about for a long time. It certainly seems to depend on the details.

Thankfully I have never had to learn this lesson first hand. I just adopted it. I remember the look in my ex-colleague's eyes.

Swamp Waders and Watchmakers

2009-03-18T10:32:00.002+11:00

I used to be a nasty hacker. I mean I used to write horribly twisted unmaintainable code.

It was as if this was my manual. It was fun!

But much later, after I finished high school and then university and eventually started being paid to write code, I started to work on systems which did not have the property that all of the concepts and implementation details of the system were in my head.

I began to prefer cleaner code.

Cleaner code led to fewer mistakes, faster changes and relied less on memory of the system when returning to it after an absence.

When I started to prefer cleaner code and worked for a while on systems where the code was comparatively clean, I started to sense a kind of allergic reaction whenever working on code which was disogranised, inconsistent and swamp-like.

It disgusted me and my occasions of exposure to the swamp were overwhelming. I have worked with guys who slithered past the many traps and gotchas, unmoved to clean up. I remembered that I used to be like them.

I remember never really thinking about the meaning of names. Why not just "x" or "w", or "foo" or "grandma"? I expected just to have my own symbol table in my head. Keeping all the mess in my head was a sharply honed skill.

I was a swamp wader. But I have since evolved.

I had become more like a watchmaker. I chose to keep things in their proper place. All the delicate sprockets and springs, neatly arrayed on sea green felt.

With everything in its place I refactor with confidence to bring the few strays into line. I revisit forgotten code and my expectations of being insulated from failures in unrelated parts of the code are capably met by the beautiful mechanisms. Names infer purpose. The code speaks for itself. I sought to only work with like minds.

Unneeded, my swamp-wading skills dwindled.

But sporadic outings into swamp lands were disorienting so I started to worry that being a pure watchmaker put me at a disadvantage. What if a nuclear holocaust wiped out all the quality code and I was forced to fend for myself in the swamp? How would I put food on the table and gadgets in my pocket?

I knew I needed to train myself. To follow a regime of tortuous swampy puzzles. Like writing Perl. And assembly. To maintain my mental toughness.

These days, decades after I began in the swamps I no longer suffer from the watchmaker's nervous discomfort in the presence of swampy code. I wade in when I have to. I do tend to cultivate things a little here and there but resist creating islands of pond-scum topiary amidst the impossible wilds. When I can I will isolate and subdivide. I'll leave signs and make paths. If there is time I may do more, but sometimes I just have to get dirty.

And I Want an iPony

2009-03-04T10:10:00.004+11:00

I have recently joined that elite set of wankers, the iPhone users.

It feels good. As people say, it's like living in the future.

Of course, being a software developer I can't help wondering how plausible it would be for me to make it rich by making an addictive physics puzzle game or something and flogging it on the app store for a couple of bucks. It certainly is incredibly easy to buy stuff.

My first purchase was iGo, an implementation of GNU Go with a slick user interface. So now I can work on strengthening my game on the bus. The perfect compliment to that is a free IGS client, Tetsuki so I can be beaten at Go by Japanese children anywhere, any time.

I won't bother enumerating the vast array of personal efficiency gains I believe I'll make.

The device is capable, luxurious and respectful of my time.

It has also exhausted my meagre toy budget for some time to come.

Too many unit tests? It Always Depends

2009-02-28T08:41:00.000+11:00

The correct answer to all non-trivial questions in software development (and a great many other things) is "It depends". Knowing this shows experience. But the correct question is really "What does it depend on?". Knowing the answer to that shows true wisdom.

Let's take a topic which has received some attention by august luminaries recently about the extent to which one should write unit tests. Your first reaction may be, "Really, people are still debating this?" Well yes they are.

Joel Spolsky and Jeff Atwood are debating this.

As much as Joel makes me chuckle and as much as he clearly has experience shipping quality software (full disclosure: the company I work for, Atlassian, happily competes with his flagship product), Joel has seemingly just levelled up or something and is going around with Jeff Atwood and challenging what I call "blind completeness" in unit testing practices.

Well I'm sure anyone on my team (JIRA) could come up with some plausible practical scenarios where additional unit tests do not repay the time spent on them. Unit tests are to catch regressions and to act as a jig keeping the code still as you maximise the design for maintainability. They also act as an index of working features (as opposed to fictional specifications). If the software won't ever be modified, then the time spent on unit testing will be waste. Just like all risk management work carried out where the maladies don't arise. And insurance policies on which a claim is never made.

It's possible that a turn of events will occur such that a given set of unit tests were unnecessary. It's not theoretical, it's practical. And it's wasted time, and for a business owner like Joel, that's wasted money. It completely makes sense that he's thinking about this. He needs to run his software business and he needs to use this fact about the possibility of wasted money to his economic advantage. Go Joel!

So what action should one take with this practical knowledge?

Here's what Jeff Atwood says:

The longer I think about this, the less I care about code hygiene issues (laughs). Because the unit of measure that really matters to me is, how quickly you can respond to real business needs with your code. And by that I mean, how well are you serving the people that are using your code. To me that's what it's all about.

Absolutely. Except over what time frame? Just this week? Don't unit test at all then.

Code quality, specifically effective unit test coverage is a leading indicator of the future ability of that code to respond to real business needs. That's why this apparent front-loading is so central to agile practices. It's the only kind of optimisation that cannot be premature if you care about the future cost of change. Optimising for maintainability is the single most critical practice for enabling change. It is not necessary to understand this about agile processes in order to get value from unit testing, however.

As an aside, watch what magnificent apoplexy happens to Kent Beck when his You Aren't Going To Need It (YAGNI) mnemonic is turned on his own advice about up-front testing.

So the question in the terms of my opening statement is:

"How much should I unit test?"

...and the answer will not surprise the attentive (or experienced):

"It depends".

And...

"What does it depend on?"

There are two factors:

How much does the test cost to create and maintain? Like all code, tests are relatively cheap to create. At least when you compare to the typical total cost of maintenance. For some reason the figure that stuck in my brain from reading some oft-cited book that I've long-forgotten (Peopleware?) was a ratio like 4:1 maintenance. If anyone can find me a citation I'd be grateful.
What is the cost of bugs in production? You could put this another way: what is the benefit of the test catching a bug before it gets into production. This cost is not a dollar value. It's a dollars over time curve.

The cost of bugs in production to a software shop like Joel's is the loss of customers or goodwill due to a customer's bad experiences with the software. And to make matters worse, you may not ever find out that the reason a customer didn't purchase or renew a license was their experience with bugs. There may be some potential for getting sued, but to my knowledge this doesn't happen in the development tools product world. Medical software? Perhaps. So there's at least one thing it depends on.

For completeness I'll mention some second order effects of bugs in production. Sometimes the bug never manifests but the assumptions evident in the code lead maintainers to draw incorrect conclusions about the system invariants. This can lead to bugs that do manifest. Don't make the mistake of thinking this is a theoretical problem.

The biggest problems with measuring the cost of bugs in production are that the cost is not immediate and often not simple to trace. There's a huge time delay. Bugs can sleep for years. And of course, if your customer base is growing then your potential loss due to the impact of bugs is also growing. If your customer base is tiny (as with fledgling start-ups and many internal IT department projects) then the cost of bugs in production is sometimes much smaller than for an established software product with millions of users. There's another thing it depends on.

Some software is sold on features, others on reputation or marketing. If you are a big name you can make money selling poor quality software at a high price because the purchasing decision-makers do not personally evaluate it nor are they fired for buying from a big name. Of course while business people can be perfectly happy shovelling this kind of shit, good developers rarely are. But there's another thing it depends on.

Further, the mechanisms for the impact of the cost of bugs in production often lean on non-development parts of the organisation like support and sales. It may be a cost coming from someone else's budget! Perhaps the project sponsor doesn't care about that budget! I would bet Joel does care because it's his company. From the point of view of the project sponsor, it depends on this too.

Clearly the economics of bugs is all about knowing your business, your customers business and the role of the software in it. And your market. And your pricing. And your customer's purchasing decision process. It depends on all this stuff.

You need to know the time frame over which you are measuring the cost-benefit trade-off of being at your sweet spot on the quality curve. This may also change over time. Sometimes it's critical to "get to market". Other times it's super critical. In my experience getting to market only ranges between these two.

All this stuff is just basic cost-benefit analysis and there is no magic formula that will work across all software projects. There's too much variation. Of course this doesn't stop pundits from continually declaring which size fits all.

So now in terms of Robert Martin's blog post, Quality Doesn't Matter That Much -- Jeff and Joel. My response is. It bloody depends. Software developers need to be able to speak to their project sponsors in terms such that they can negotiate the optimal quality balance for the circumstances.

Finally, if you are a software developer working on a project for whom the cost-benefit trade-off that has been decided by your project sponsor leaves you with a quality level that robs you of job satisfaction, then drop me an email.

First Post!

2009-02-26T10:22:00.001+11:00

This is the inaugural post of my new blog on the topic of software development and other stuff I like. As I write I hope my adequately configured blogging software makes that sentence redundant.

The thing that was stopping me starting a new blog in the past was the effort of retrieving my old blog's posts which are stored in a database dump in a tarball on a drive somewhere. As the value of keeping and restoring my tired old rants into a new blog approached zero and the idea of just starting afresh maintained its appeal, I ultimately reached the threshold where my impetus to write exceeded my resistance to giving up on them.

Perhaps there's just enough room left to succinctly justify my pushing my opinionated commentary on the world in case of the minuscule possibility that this first post will be read by someone.

Actually, let's just say I'm only doing it for the money.