skizz.biz

Update: So it turns out iPhones *do* have a way to turn it off but its just that I at least never read the manual (because you don’t need to) and didn’t discover it. My main point is still interesting I think, that you don’t need it enough to want to find it. As usual I will leave my mistake here for the word to read. :-)

Apple get usability. By now there must be very few people who don’t realise that. But in case there are some out there, lets just look at a couple of examples that struck me recently.

I own an Apple iPhone. I bought it in San Francisco, unlocked it myself, and have been using it constantly for the last month. It is without question the best phone I have ever used. Not perfect, for all the (3G etc.) reasons that you can read about on the blogsphere, but it is pretty damn close, and certainly closer than any other I have owned, including my abortive attempts to get to like “smart phones” in the past (Palm, Nokia etc).

But it struck me after a month of using the thing that there is a glaring missing feature. In fact it is so obvious I’m astounded that I haven’t noticed it before. There is no ‘off’ button.

There is a button on the top right that you press to lock it - the screen turns off but little more.

There is also a ‘be quiet’ button on the left side, above the volume control. Hit it, and the phone gives a little shake and then remains silent. This is equivalent to choosing the ‘Silent’ profile on a Nokia or other phone.

The most amazing thing about the lack of an ‘off’ switch is that you never notice it. Hey, it took me a month. And when do notice, and start to think about it, you realise that you never actually needed an off button anyway. The only reason that I used it on my old phone was because I was going into a meeting, and I wanted to make sure I wasn’t disturbed.

But this shows the reason that Apple doesn’t need it. With my old Nokia, ‘Silent’ was a profile, and I had to trust that the people who created that profile did the right thing, and turned all the sounds and notifications off. That they didn’t think “You know, this feature that I’m working on is really *really* important — no-one would *ever* turn it off — so I’ll give an ever so subtle beep even in Silent mode”. I don’t trust anyone to do that. I don’t trust *myself* to do that if I’m developing software.

So what Apple does is say: “No, this isn’t an option, its not a profile that you can customise. No questions asked — hit this button and I won’t disturb you. Not at all. Never”. It is still a trust issue. But I trust that button. I trust it because it doesn’t feel like a software option — the button implies a hardware solution — a built in switch that kills the sound. (Of course I understand that in reality it is software, but trust is conveyed by the visceral physical click of that button).

Apart from wanting to make it silent, why would you ever turn off your mobile? These days turning off a mobile is like locking yourself in a dark room and calling out to your friends that you aren’t coming out. Life — or at least social life — stops [1]. So the Apple iPhone has no off button.

Another shorter example. I am writing this sitting outside the Apple store in NY. You know the one, the glass box on 5th Avenue. Every couple of minutes someone takes a photo of it. It is beautiful, ad the plaza that surrounds it is comfortable and popular and full of people sitting eating lunch. A shop that gives something back. Nice.

Inside the store, it is very busy, very crowded. Apple stores have the highest per foot profitability of any store here. But it is still cool and comfortable and a pleasant place to be. But it is quite noisy. So how do you sell iPods, which are ‘all about the music’ as Steve Jobs likes to say in a noisy environment?

I don’t know how other companies would do it, but what Apple do is load all the iPods on display with Bose sound cancelling headphones. These are the $250+ headphones that you see long distance travellers (like me) using on long haul flights to cut down the airplane noise and get some sleep [2]. Despite the noise in the store you really can hear the music, and the chaos of the store disappears when you put them on.

This is the attention to the user experience that has made Apple what it is. It is pleasant to visit an Apple store. It is pleasant to buy an Apple product. It is pleasant to use an Apple product. And it is why the Apple iPhone doesn’t have an off button.

[1] While writing this it struck me that the same is true of my laptop. I never switch it off, I just close the lid. And that makes me wonder if we will someday see a laptop from Apple that has no off switch?

[2] They are using the AC3 ones that sit on the ear, and I guess that is because a used over the ear headphone might feel unsanitary, whereas the on the ear design leads to less actual contact. They are not the battery operated ones though, I don’t know what exact model they are.

While in San Francisco recently for a meeting, a group of ThoughtWorkers got together to record some podcasts. The first has now been posted here:

In this two-part series, Martin Fowler, Chris Stevenson, Jim Webber, and Sriram Narayan discuss REST (Representational State Transfer). They touch on the history of REST, a detailed explanation, and examples. Additionally, they discuss programming with the Web today, modeling your resources, types, RESTful enterprise development, and reuse.

http://www.thoughtworks.com/what-we-say/podcasts.html

Many codebases suffer from an accumulation of technical debt — small sub-optimal fixes and tactical decisions. Each of these probably made sense at the time, and we always intend to come back and fix them, but somehow never have time. Ratcheting is one technique that may help to address this problem.

The Problem

You are on a large codebase in a large team. The codebase hase been around for a while, and as always in these cases, has accumlated some technical debt. These are mostly simple things that would be easy to fix, but there are so may of them that it can be hard to see where to start. And since you are busy releasing new versions and working on new features, it is hard to find the time to just work on these trivial things.

But just leaving them is bad too - since this lead to an acceleration of problems. If there are 100 warnings, then 101 is not so bad, is it? If there are already 30 ignored tests, does it really matter if I ignore this test? These are the sort of simple day to day compromises that lead to a long term deterioration in code.

This is the boiling frog syndrome — where a small incremental change is not noticeable but over a long period of time there is a significant change.

Another example is build time. Over time our builds tend to get longer, and while today’s build may only be a second or two slower than yesterday’s, over a year or longer we may be looking at significantly slower builds.

Avoiding this is one problem. Another is fixing it when it has occurred, but you can’t take the development process offline to just fix the technical debt.

It is easy to say ‘the build should be no longer than 10 minutes’ but what do you do if it is currently 20 minutes? What do you do if you have hundreds of build warnings, or FxCop reports thousands of (mostly trivial) problems?

Ratcheting

A ratchet is defined as “a ratchet is a device that allows linear or rotary motion in only one direction, while preventing motion in the opposite direction.” — Wikipedia

What we are trying on our project is a software version of the ratchet. The approach is fairly simple, and consists of the following steps:

Identify a problem — Choose one of the issues that you have, and find a way of reducing it to a number. Examples are build time, the number of ignored tests, the number of enums, switch statements, code coverage or pretty much whatever you can count.

Stop it getting worse — This is the crucial piece. In every build, check the number, and compare it to the number in the previous build. If it is ‘worse’, then fail the build. Of course what ‘worse’ means differs for different metrics. Build time is worse if it goes up. Coverage is worse if it goes down.

Make it better (optional) — In this step you fail the build if the number doesn’t get better. I think of this as tightening the screws. I like to think of it as a reference to literally tightening loose screws on some kind of machine. But done badly it could be a reference to tightening thumbscrews to torture people. A tyrannical ‘architect’ doing this could kill team morale. On the other hand if the whole team agrees to it and chooses the thing to ratchet then it can be a positive reinforcement.

This means that every time someone checks in, they have to remove one of these items. It may be simple, as in fixing one build warning, or more complex, as in improving code coverage. It will affect productivity a bit, but only a little bit for each checkin. It makes sure that everyone takes responsibility for fixing the problems in the code. Done well, I think this can enhance the team.

Repeat — There’s a lot left to do. Choose another metric. Keep the previous ratchet in place, or you will lose the benefit.

Trying it out

On our current project, we have 85 ‘TODO’ comments in the code. This is classic technical debt. Who knows if these are still valid? We have turned ratcheting of these on in our build to test the idea. With a team of 7 pairs, it should only take us a few days to get that to zero. I’ll let you know how it goes…

At TED in 2007, Hans Roslings announced that the UN had agreed to make their data freely available. Previously it was paid only. 

Well they have not only followed up with action, they have done it in style.They have just introduced a new website where you can query all the databases. It is features a very nice google style search, with lots of ajaxy goodness to make finding data even easier.You can find it here : http://data.un.org/.

It is early days yet, and all the data is not there, but you can already do some interesting searches. Some rather peculiar ones too. For example, you can find out how many Internet users there were in the world from 1960 to the present. Here is the data for 1960 : Internet Usage in 1960 - 30 years before Al Gore even invented it :-)

I have been interested for a while in the idea of the ‘corporate mashup’. What could be done with corporate data mashed up with things like Google Maps and other visualizations? I found this one today from the World Bank — summaries of its projects in a Google Maps mashup.

http://geo.worldbank.org/

It is also very good to see that these organizations are starting to open up access to this information — triggered in no small part by Hans Roslings at Gapminder.

Owen and Fiona have been here in China for the last 6 months, and have just headed back to Vancouver, Canada. I have worked with Owen in many countries around the world, and it is sad to see them leave so soon after I got here. A group of us from the office went to a local gyoza joint for dinner and to say farewell. There are a few babies around, and it made me realise how much ThoughtWorks can be a global family. Photos here.

I have been continuing the ThoughtWorks tour, and have finally made it to the China office, in Beijing. The office has just moved here from Xi’an, and so the Monday that I arrived was a busy one, with old friends re-connecting, and the office rapidly filling up. In fact, we have very little room left, and may have to start find new space pretty soon. Once I have a few more photos, I’ll post a gallery of office photos. It is pretty much along the lines of other TW offices, a large open space with flat ‘dining tables’ and a very fun, collaborative feel.I was lucky enough to get here in time for the ThoughtWorks Away Day.

On the Sunday we went to the Great Wall near Beijing. The gallery is here (I haven’t put these on flickr yet, since it s blocked by the great firewall. Sigh.).

I guess there are always a few things that we don’t tell our parents until after the fact. No, get your minds out of the gutter, I don’t mean that. I mean the sort of thing that mother’s don’t need to know. They would only worry for no reason, so let’s spare them that and fill out the details later.

This was one of those. Recently the ThoughtWorks India office went to Ooty for an Away Day. The Away Day is a weekend technical and cultural fest (basically it involves geeking during the day and drinking and dancing at night) and in India we generally bus to somewhere within a few hours of Bangalore and spend the weekend there. This year was in Ooty, which is a hill station about 280km from Bangalore, past Mysore.

The route takes us to Mysore on one of the nicest South Indian roads (divided higway with 2 lanes each side), through Bandipur National Park (home of Project Tiger) and up a spectacular road to Ooty itself (36 hairpin bends).

A few of us felt that this was too good an opportunity to pass up, so with the help of Royal Enfield we got together some bikes, and the 14 of us took off at 7am to bike the 280km. For anyone who has not experienced the roads here, that may sound like a fairly quick jaunt. In fact, it took us about 12 hours each way. But the trip was awesome, and well worth it.

We were supposed to leave at 7am from the Bangalore office, but due to various issues, we were actually only able to leave by about 9:30. We drove for about an hour through Bangalore’s insane traffic, and ended up stopping for chai on the outskirts, near Bangalore University.

Rest stop before Mysore. Sagar picked up the sugar cane from a load that had been left on the road after a truck tipped over. This is fairly common here, as many trucks are overloaded and top-heavy We saw 2 just on the way to Mysore.

Rest stop after Mysore.

Lunch outside Gudalpet. We were waiting for Dheeraj, who was involved in a minor accident in a small town near Mysore.

Chai on the edge of Bandipur National Park.

Waiting for us at the petrol bunk.

At the bottom of the hill, we thought “Maybe we should fill up?” but it was getting late, and we felt that we were OK. famous last words of course. As a result we had to wait around while Keshav went off to find us some petrol. Luckily we were at the top of the hill, quite near Ooty, and there was an excellent chai stall.

The view from the hotel in Ooty.

Playing cards, Sunday night in Ooty.

Ooty — waiting for people to wake up

Ooty — Mechanics shop - playing cards again.

Coming back on the Monday, we hoped to leave at 10am, but we needed to get one of the bikes seen to first. It had lost the top gear. Unfortunately the mechanic took a long time to arrive, and when he did there was little he could do, so we had to ride it back to Mysore without a fix anyway. So we ended up leaving quite late, about 3pm.

One of the 36 hairpin bends on the Ooty road. Near here, a car had gone over the side earlier in the day, falling down a sheer 100m drop. On the way up, we had done this road in the dark, and the rain. I’m kind of glad we couldn’t see the view, even though it was awesome coming down.

Bandipur national park.

This is the home of project Tiger, and one of our colleagues who drove back apparently saw one with cubs crossing the road, which is extremely rare, as they are quite shy. Deer and elephants are common though. We came upon a group as we rounded a corner, which was quite a shock at first, until we noticed that they were chained and domesticated. It is mating season right now, and wild male elephants (called ‘tuskers’ here in India) can be quite touchy.

Elephants in Bandipur

In Bandipur Keshav ‘distinguished’ himself by riding standing up and generally fooling around. It is relatively safe on the Thunderbirds since they are pretty stable at the low speeds we were doing, and there was not so much traffic in Bandipur.

Riding to Mysore In Mysore we stopped while the bike was seen to. It turned out to be a long job, so we ended up leaving the bike there. The dark green bike here is a very rare diesel model produced by Royal Enfield in the 70s. Yes, you did read that right, it is a diesel motorbike.

On the way back, in the early evening, I dropped the bike near a speed-breaker (aka speed bump, sleeping policeman). These are very common on Indian roads near cross roads and the entrance to towns, even on what you might consider a ‘highway’. Sometimes, as in this case, they can be very poorly marked. None of us saw it in time, and the vehicles in front of us also braked very late. My front wheel locked, and as any motorcyclist would tell you, once that happens you are not going to stay upright. Fortunately I was going slowly, and suffered only bent pride and some scrapes on elbow and knee.

Sripad was shaken up a bit by seeing the accident, and he himself came of the bike a few 100m later, as a result of hitting a pig. These are the hazards of Indian roads. Both he and the pig were fine.

Recovering at Coffee Day, half an hour after dropping the bike.

Murphy’s law hit later on I guess, when about 2 hours later the bike started acting very strangely - and handling like a sofa. I thought it was my imagination at first, then it was getting much worse. Naturally I assumed it was the after-effects of the accident. I swapped with another rider and when he rode off I noticed that the back tyre was going flat. This was at 10:30 at night on a Sunday, and when we stopped at a (closed) petrol bunk, I was pretty sure that it was a forlorn hope to find someone to fix it.

Repairing punctures

Fortunately in India there is always hope. It turned out that there was a puncture shop a couple of kms back in the last town, and miracle of miracles, they were still sitting around drinking chai. A hundred rupees and we were back on our way. For me there were no more problems, although Keshav managed to have some fun when his muffler fell off. He carried it back to Bangalore, and eventually, after an event filled ride, we all made it back safely.

All in all it was an eventful, painful, wet and wonderful ride. It was a great way to travel, and hopefully it won’t be the last time I ride a bike across India. I’ll still wait till afterwards to tell my mother though.

I have been spiking migrating our project’s InstallShield scripts to Wix. There are several good reasons to do this, which I will get to in another post.

But when trying to decompile the InstallShield msi using Dark I get the following error:

dark.exe : error DARK0001 : Cannot set column 'KeyColumn' with value 0 because it is less than the minimum allowed value for this column, 1.

Exception Type: System.InvalidOperationException

Stack Trace:
   at Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Object value)
   at Microsoft.Tools.WindowsInstallerXml.Unbinder.UnbindDatabase(String databaseFile, Database database, OutputType outputType, String exportBasePath)
   at Microsoft.Tools.WindowsInstallerXml.Unbinder.UnbindDatabase(String databaseFile, OutputType outputType, String exportBasePath)
   at Microsoft.Tools.WindowsInstallerXml.Unbinder.Unbind(String file, OutputType outputType, String exportBasePath)

It turns out that InstallShield doesn’t put the right values in the _Validation table (whatever that is). Some hints are in this bug. It is next to impossible to fix it from the InstallShield side, so I did it by fixing the Wix side.

Note: You need to check out the CVS version of Wix to build it - the source downloads from the website do not work. No documentation on this anywhere of course. Sigh.

When you have the code compiling, the hack is simple - modify the columnDefinition for KeyColumn in the file src/wix/Data/tables.xml to allow 0’s in that column. Note that this is a hack not a solution. This may cause other problems and probably the Wix guys will need to fix this for real, maybe by supplying a default value. But it did allow me to export the MSI successfully.

Patch against the latest cvs:

Index: src/wix/Data/tables.xml
===================================================================
RCS file: /cvsroot/wix/wix/src/wix/Data/tables.xml,v
retrieving revision 1.49
diff -u -r1.49 tables.xml
--- src/wix/Data/tables.xml	21 Sep 2007 07:58:40 -0000	1.49
+++ src/wix/Data/tables.xml	21 Nov 2007 14:32:05 -0000
@@ -1482,7 +1482,7 @@
         <columnDefinition name="KeyTable" type="string" length="255" nullable="yes"
                 category="identifier" description="For foreign key, Name of table to which data must link"/>
         <columnDefinition name="KeyColumn" type="number" length="2" nullable="yes"
-                minValue="1" maxValue="32" description="Column to which foreign key connects"/>
+                minValue="0" maxValue="32" description="Column to which foreign key connects"/>
         <columnDefinition name="Category" type="string" length="32" nullable="yes"
                 set="Text;Formatted;Template;Condition;Guid;Path;Version;Language;Identifier;Binary;UpperCase;LowerCase;Filename;Paths;AnyPath;WildCardFilename;RegPath;KeyFormatted;CustomSource;Property;Cabinet;Shortcut;URL" description="String category"/>
         <columnDefinition name="Set" type="string" length="255" nullable="yes"

I am in Pune for a couple of weeks giving the ThoughtWorks Object Bootcamp training. It was a public holiday yesterday for Mahatma Gandhi’s birthday, and some of us went out to Singhad and Panshet Dam for a mini trek.