Apples and Pears

I bought a MacBook Air the other day. What a breath of fresh air.

I've been a fanboi now for a little over a year, having bought my iPhone 4 from the Apple store in Brighton the day after it was announced - I was initially taken aback by the £500 price tag but if you look, they are still being sold on Apple's website for £510 and you will need to pay £300-£400 on ebay for one second hand. Add in a £15 per month tariff and my costs are well under £30 a month. I could probably write a whole blog post on that subject alone ..

Anyway, the MacBook Air. Did you guess that I like it?

I should point out that my 'work' laptop is an i7-based affair running Windows 7 with all the corporate junk you'd assume - disk encryption, virus checker, domain membership and associated policy restrictions, firewall, etc. etc.

I spent most of the weekend using the Mac - browsing, downloading, using iWork, trying to understand Xcode and reading the Objective-C getting started guide. It was a pleasant experience, but I have to say that it didn't particularly impress me - it (as they say) "just worked" and I got on with what I wanted to do.

It wasn't until Monday morning when I arrived at work and resumed my hibernated work laptop that I was shocked. It took forever to get started .. I just sat there whilst it resumed first, then took the best part of 2 minutes to present the desktop. And then I needed to fire up Outlook which, predictably, seemed to take another 2 minutes .. and then it needed to download all the emails from the weekend.

Whilst all this was going on, I powered up the Mac. It turned on instantly (perhaps a few seconds) and was ready to go. If I were able to, i'd have been in my email and being productive a good 10 minutes before the PC.

I am sure it's an unfair comparison in some respects, i'm sure the PC is doing more work *somewhere* and i'm sure that, given the same OS and SSD drive, the i7-based laptop could perform better. But life isn't fair and i'm not really interested in making a PC go 'as fast' as a Mac. I just want to use the Mac.

The performance difference is enough alone, but looking at the way the hardware and OS works together it makes the experience even better - a massive touchpad and gestures with Lion just mean that you can really get productive. I was looking for the 'virtual desktop' feature in Windows 7 tonight - it isn't there. Infact, it was a power toy for a while but seems to have disappeared. Why on earth? Apple have just made it work beautifully and for the first time since I first used virtual desktops on a Sun SparkStation i'm using them again .. intact the whole experience with the Mac reminds me of the opposite experience when I moved from Sun workstations to PC's .. the PC felt clunky back then and i'm sad to say that it feels clunky right now.

Remind me again why i'd want to use Windows?

Housebuilding

We all know the analogy - developing software is like building a house. This patronising explanation typically followed immediately by the follow-up that we need to get the foundations right before we start building any of the walls, let alone start plastering, wiring or putting the roof on.

But just how valid is this comparison and does this help or hinder? One would suspect the former, and it would seem reasonable, given the obvious pitfalls of not thinking through the solution in its entirety before cutting code. I mean; consider the effort required to convert a large system between .Net and Java if you discovered that you needed the portability that the JRE offers? Or the sheer hassle in migrating from Access to Oracle because you thought it was a 2-user system and it turned out to be 1000-user?

Clearly there needs to be some forethought, but is it really comparable to getting to the roof trusses and realising that your foundations weren't deep enough? Or that your 4 bedrooms don't fit onto the 2-bedroom foundations that you've laid? In both these cases you'd effectively have to go back to scratch and start again. But converting from Access to Oracle? Well certainly it's a lot of work, but if you've architected the system properly - separation of concerns, etc. then why would you need to change your GUI code? Or the logic you've coded in the middle tier to assess claims, or the link to the third party system for payment processing?

Ok, so perhaps not quite the same thing, but still - something that we should avoid? Fools rush in/etc.

But there is more that the analogy doesn't consider. And these things are significant - how about continuous integration? How does that fit with housebuilding? Or the agile concept of features and 'done', or test driven development? These are all development techniques that seek to test as much as possible as early as possible, identify defects as soon as they are introduced and improve estimation. We all know these are sensible but how does this correlate to housebuilding? Perhaps we should be recommending that a building builds all the way to the roof in one thin turret so that we can 'test' that the roof is watertight (an 'habitable room' feature)? Or that he builds scaffolding to the exact size and shape before laying bricks (TDD)?

It doesn't make sense. And these are good examples of why development - even green field in this case - is fundamentally different from house building. When you start to look at brown field the comparison is even less valid.

So we're going to build an extension every month. When is the last time you asked a builder to do that? Ok, you might argue that some product evolution is more like wallpapering every so often, or re-painting the skirting boards. But that isn't my experience and I'd attribute this pattern more to legacy, regulatory-driven or end-user customised COTS packages. For line of business applications challenged with keeping up with the business or commercial offerings keeping pace with competition, there's a significant amount of change and IT have to be able to accommodate this change regardless of the 'structural' impact to the system.

So one week it might be some wallpapering, but more than likely it's converting the single garage to a double, adding toilets, enlarging rooms, etc. And then there is the case of the upgrade to particular components - I'm not sure the last time Ikea released a v2.0 of their 'kitchen' and forced everyone to upgrade, but that's what happens ..

So the more I consider the analagy the more I think we need to take it with a pinch of salt. And any decisions based fundamentally upon it should be very carefully considered.

No decisions = no achievements

Few successful businesses are built by people afraid to make decisions. It's often said that it is better to make a bad decision than to not make a decision at all. But is that really true? Surely there is a fine line between being decisive and just randomly choosing a wine because you like the design of the label or booking a flight because you like the person behind the checkin desk?

Sure, you can't just go shooting from the hip all the time and expect that your ultra-decisive, sharp, go get 'em business will leap ahead of its competitors. But conversely don't expect that indecision will have no impact on your efficiency and profitability.

It's easy to find risk - there's risk crossing the road, risk sending your kids to that local comprehensive, risk getting up in the morning. But we need to be able to use our experience and expertise to assess the risk without explicitly mitigating everything. Crossing the road is a good example - you wouldn't look for a pelican crossing every time you cross - you naturally assess the risk and take it where appropriate. And actually, there's sod all you can do about it when Terry comes round the corner in his GTI, loses it and skids sideways into you - that's just life.

So lets look at a real life example - we're considering adding a featureset to a product. The ROI is attractive, the business are happy with the estimate and what happens? We start asking questions ..  we start looking for risk, we start considering other options, under the cover of 'due diligence' we pour effort into ratifying what our experience and gut has been telling us for weeks.

In short, we dither. And miss the opportunity to be decisive, to prove to our customer that we know what we're doing, to demonstrate value quickly.

We certainly become well versed in all the options, their costs and the potential pitfalls of our approach. But when's the last time you were attracted to a know-it-all? More to the point, when's the last time you gave one part of your IT budget and said 'get on with it' ?

The art of software

I've long thought that development is much more of an art than many people realise. Even people within the industry treat development as something which needs to be specified and that developers are little more than typists who seem to make frequent spellig and grammer mistakes ;-)

It's a strange view, but lets face it - development is fantastically artistic. There are many, many different ways to create a CRM system, many ways to build an email component, thousands of ways to create a user interface page which captures information from a user.

And in the 'real' world, we accept that some tasks have an engineering part and an artistic part. Take Terminal 5 at Heathrow airport. It has some obvious (and substantial) engineering requirements - it needs to accommodate over 30 million passengers every year and all the accompanying baggage (literally). And yet we are quite prepared to accept the clearly artistic approach taken by the Richard Rogers Partnership who designed the building. It exposes many of the structural elements to the users of the terminal and, although very much in the eye of the beholder, is acclaimed for its artistic elements as well as the engineering which has gone into the construction. You can argue the same for many other buildings, bridges and even the odd consumer device of late. The 'how' is as important as the 'what' - not more important, not less, but equal.

So are we treating development the same way? I see little evidence - we continue to focus on the engineering and leave little room for artistic flair. And why should we? What is the point?

I wonder whether anyone ever asked da Vinci, Brunel, Richard Rogers or Norman Foster?

Planning & preparation versus agile

Many of the interesting agile discussions I have are with those whose job has an element of 'crystal ball' about it. No matter how crazy this might sound, this is what we try and do time and time again whilst delivering IT - we tell the customer how long it will take, we tell the customer how much it will cost. And in many cases we also attempt to document how systems will be structured in the years to come, the technologies they will use, the interactions they will have, etc. etc.

Of course, some of this is necessary - if you don't know where the ship is heading, you might as well not leave the port. So certainly we need an idea of whether a system is going to become legacy, whether it has a future, and what that future might look like. But it's important to control the amount of effort put into this kind of work, and the message which emerges.

An estimate given before work commences is just that - an estimate. It should be accurate enough to set expectations appropriately but at the end of the day, its only based upon the data we have at the time and our past experience. The same is true for any kind of strategic planning or design work - what is often overlooked is what we don't know. We don't often know the complexity which will arise out of the development of a particular component, we don't know that we'll find a tool on the web which can simplify our email template editor, we don't know that the business will cancel the project and complain that they've sunk £1.8M and received no benefit.

Lets get back to the primary goal of software development - the engineering of software which supports the business and allows it to operate efficiently. At its heart are the developers - the 'coalface' workers, and our responsibility is to minimise the work which isn't actually chipping coal from the coalface - everything else is less useful and unless tightly controlled is simply waste.

But we can't just go developing code randomly without a target in mind. And the customer is funding all of this and expecting some benefit, so they need to understand how long and how costly this will be - that's entirely understandable.

Agile can really help here - it is simply a matter of when and how to communicate. I think we would all agree that when a project kicks off, we need to get some brains in a room and discuss options. There's a lot of ground you can cover in a few hours with the right people. You can set the approximate direction, the tools you'll use, the objectives, etc. If you get the business involved we've seen huge leaps forward with gathering requirements (user stories) and success criteria, dependencies, etc.

So you have a couple of kickoff meetings. At this point you've spent next to nothing and should have a very rough idea of the size of the project (S-M-L-XL), the features it will deliver and the benefit. Enough to secure funding for a small team to execute a few sprints? If not, you're doing something wrong.

Once the team is up and running you'll have the experts on the case - developers will be able to get their hands dirty, the testers will be able to get to grips with any complexities, and we'll be deploying at the end of every 2 weeks so will understand what it takes to get the code released. In short, we'll touch every part of delivery and will build up experience.

After 3-4 sprints i'd recommend a major checkpoint to validate that the velocity is appropriate and burndown shows delivery at a suitable point. Now is the time to can the project, continue, or inject some investment (additional teams?) to potentially speed up delivery. The decision is in the hands of the customer but is based upon fact rather than crystal ball.

Strategic planning isn't irrelevant - it's the backbone on which the meat of development sits. But it supports development, rather than constraining it. Of more concern is the planning & prep work which we attempt on each project - we need to spend more time learning from development teams rather than second-guessing what they will do in the misguided hope that this somehow makes us more efficient. In many cases, the opposite is true.