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