This year’s edition of India’s foremost Free & Open Source Software event will be held on December 15-17, 2010, and the venue will be again the NIMHANS Convention Centre, same as last year.
There are several differences between this edition and previous ones:
Duration:
This year, the event is 3 days instead of the usual 5 days - a 5 day event was simply too exhausting for everyone (participants and team). Also, we have moved the event into the middle of December, to give students of colleges that usually have their exams end-November or early-December a chance to attend. Our American friends will be happy to note that we have moved the event safely out of Thanksgiving range
Scope and content:
As has been made clear since last year – we are enlarging the scope of the event to include more technology. While FOSS is still very much the heart of the event, we are encouraging people to be more involved in technology, and get into the “hacker mindset” that has been the basis for the FOSS movement across the world, but has been more or less avoided here in India.
Note to the media: “Hacker” is a good thing – it refers to a person who pushes the technological envelope, and extending technology beyond its known limits. What the media has been calling “hackers” is really “crackers” (criminals who break into computer systems and networks). We will have a separate note for you soon on this subject).
The content of the event will reflect the technological scope of FOSS.IN – there will be more practical hands-on, more “workouts”, more workshops, and fewer talks and tutorials. This is in line with our credo “Talks is cheap, show me the code”. More details about this will be in the Call for Participation that will be published on August 30th, and also in posts following this one.
Funding the event:
As most of you know, funding an event such as FOSS.IN is a hard problem, and to avoid the problems we ran into last year (the less said, the better), we are making some changes that were long overdue:
While we are keeping the participation fee for students the same (Rs.500, or about US$11), which includes the cost of lunch and tea/coffee, we are raising the fees for individuals to Rs.1500 per head, and to Rs.5000 per head for corporate attendees (this will be acknowledged as support for the event). We know that some of you will complain about this, but we introduced the Rs.500 fee six years ago, and the Rupee just doesn’t go as far as it used to.
We have to unfortunately drop the travel sponsorship for international speakers, except for very exceptional cases. As we did last year, we encourage speakers to seek travel sponsorship from their employers, user groups or other sources. We will treat this as support for the event and will acknowledge this on our website. However, no changes in accommodation and other hospitality – we will continue to cover all costs for outstation speakers – bed&breakfast, (lunch is at the venue), local travel, conference fees, etc.
As usual, the event will depend on sponsorship from organisations supportive of the concept of people getting more involved in technology, and gaining a deeper understanding of it. There will be a separate note for you, but if you are keen to get the process going ASAP, please do get in touch.
Talks:
We have been steadily reducing the number of talks during FOSS.IN, because we want people to participate in workouts, but we are not eliminating talks. There will be two kinds of talks as usual – talks during the Main Sessions (ie daytime) and “hacker sessions” in the evenings and late at night. There will be one keynote every evening. More about all this in the CfP when we release it.
There are a lot of other little things that we won’t cover in this note, but be prepared, as usual, to have the time of your life.
More information will appear soon on the FOSS.IN website, and a detailed Call for Participation,Call for Volunteers and Call for Sponsorship will appear there soon.
And as usual, May The Source Be With You, people, and get ready to ROCK!
Team FOSS.IN
p.s. DO follow us on Twitter and on the FOSS.IN Mailing List to keep updated on emerging details about the event, and to participate in the discussions leading up to it.
Note that I'm using MathJax to render the equations on this post. It can take a while to render everything, so you may need to wait a bit before everything shows up. If you're reading this in a feed reader, then it will all look like gibberish (or LaTeX if you can tell the difference).
So I've been playing with this idea for a while now, and bounced it off YSlow dev Antonia Kwok a few times, and we came up with something that might work. The question was whether we could estimate a page's expected roundtrip time for a particular user just by looking at the page structure. The answer, is much longer than that, but tends towards possibly.
Let's break the problem down first. There are two large unknowns in there:
a particular user
the page's structure
These can be broken down into their atomic components, each of which is either known or measurable:
Network characteristics:
Bandwidth to the origin server ( \(B_O\) )
Bandwidth to your CDN ( \(B_C\) )
Latency to the origin server ( \(L_O\) )
Latency to your CDN ( \(L_C\) )
DNS latency to their local DNS server ( \(L_D\) )
Browser characteristics:
Number of parallel connections to a host ( \(N_{Hmax}\) )
Number of parallel connections overall ( \(N_{max}\) )
Number of DNS lookups it can do in parallel ( \(N_{Dmax}\) )
Ability to download scripts in parallel
Ability to download css in parallel (with each other and with scripts)
Ability to download images in parallel with scripts
Page characteristics:
Document size (\(S_O\) )
Size of each script (\(S_{S_i}\))
Size of each non-script resource (images, css, etc.) (\(S_{R_i}\))
Number of scripts ( \(N_S\))
Number of non-script resources (\(N_R\))
Number of hostnames (\(N_H\)), further broken down into:
Number of script hostnames (\(N_{SH}\))
Number of non-script hostnames (\(N_{RH}\))
All sizes are on the wire, so if a resource is sent across compressed, we consider the compressed size and not the uncompressed size. Additionally, scripts and resources within the page can be combined into groups based on the parallelisation factor of the browser in question. We use the terms \(SG_i\) and \(RG_i\) to identiffy these groups. We treat scripts and non-script resources differently because browsers treat them differently, ie, some browsers will not download scripts in parallel even if they download other resources in parallel.
To simplify the equation a bit, we assume that bandwidth and network latency from the user to the CDN and the origin are the same. Additionally, the latency for the main page includes both network latency and the time it takes the server to generate the page (\(L_S\)). Often this time can be significant, so we redefine the terms slightly:
\begin{align}
B_O & = B_C \\
L_O & = L_S + L_C
\end{align}
Browser characteristics are easy enough to obtain. Simply pull the data from BrowserScope's Network tab. It contains almost all the information we need. The only parameter not listed is the number of parallel DNS lookups that a browser can make. Since it's better to err on the side of caution, we assume that this number is 1, so for all further equations, assume \(N_{Dmax} = 1\).
Before I get to the equation, I should mention a few caveats. It's fairly naïve, assuming that all resources that can be downloaded in parallel will be downloaded in parallel, that there's no blank time between downloads, and that the measured bandwidth \(B_C\) is less than the actual channel capacity, therefore multiple parallel TCP connections will all have access to the full bandwidth. This is not entirely untrue for high bandwidth users, but it does breakdown when we get down to dial-up speeds. Here's the equation:
\[
T_{RT} = T_P + T_D + T_S + T_R
\]
Where:
\begin{align}
T_P \quad & = \quad L_O + \frac{S_O}{B_C}\\
\\
\\
\\
\\
\\
T_D \quad & = \quad \frac{N_H}{N_{Dmax}} \times L_D\\
\\
\\
\\
\\
\\
T_S \quad & = \quad \sum_{i=1}^{N_{SG}} \left( \frac{S_{SG_imax}}{B_C} + L_C \right) \\
\\
\\
\\
\\
\\
N_{SG} \quad & = \quad \left\{
\begin{array}{1 1}
\frac{N_S}{min \left( N_{Hmax} \times N_{SH}, N_{max} \right) } & \quad \text{if browser supports parallel scripts}\\
\\
\\
N_S & \quad \text{if browser does not support parallel scripts}\\
\end{array} \right. \\
\\
\\
\\
\\
\\
S_{SG_imax} \quad & = \quad \text{Size of the largest script in script group } SG_i\\
\\
\\
\\
\\
\\
T_R \quad & = \quad \sum_{i=1}^{N_{RG}} \left( \frac{S_{RG_imax}}{B_C} + L_C \right) \\
\\
\\
\\
\\
\\
N_{RG} \quad & = \quad \frac{N_R}{min \left( N_{Hmax} \times N_{RH}, N_{max} \right) }\\
\\
\\
\\
\\
\\
S_{RG_imax} \quad & = \quad \text{Size of the largest resource in resource group } RG_i
\end{align}
So this is how it works...
We assume that the main page's download time is a linear function of its size, bandwidth, the time it takes for the server to build the page and the network latency between the user and the server. While this is not correct (consider multiple flushes, bursty networks, and other factors), it is close.
We then consider all scripts in groups based on whether the browser can handle parallel script downloads or not. Script groups are populated based on the following algorithm:
for each script:
if size of group > Nmax:
process and empty group
else if number of scripts in group for a given host > NHmax:
ignore script for the current group, reconsider for next group
else
add script to group
process and empty group
If a browser cannot handle parallel scripts, then we just temporarily set \(N_{max}\) to 1.
Similarly, we consider the case for all non-script resources:
for each resource:
if size of group > Nmax:
process and empty group
else if number of resources in group for a given host > NHmax:
ignore resource for the current group, reconsider for next group
else
add resource to group
process and empty group
For DNS, we assume that all DNS lookups are done sequentially. This makes our equation fairly simple, but turns our result into an overestimate.
Overall, this gives us a fairly good guess at what the roundtrip time for the page would be, but it only works well for high bandwidth values.
We go wrong with our assumptions at a few places. For example, we don't consider the fact that resources may download in parallel with the page itself, or that when the smallest script/resource in a group has been downloaded, the browser can start downloading the next script/resource. We ignore the fact that some browsers can download scripts and resources in parallel, and we assume that the browser takes no time to actually execute scripts and render the page. These assumptions introduce an error into our calculations, however, we can overcome them in the lab. Since the primary purpose of this experiment is to determine the roundtrip time of a page without actually pushing it out to users, this isn't a bad thing.
So, where do we get our numbers from?
All browser characteristics come from BrowserScope.
The user's bandwidth is variable, so we leave that as a variable to be filled in by the developer running the test. We could simply select 5 or 6 bandwidth values that best represent our users based on the numbers we get from boomerang. Again, since this equation breaks down at low bandwidth values, we could simply ignore those.
The latency to our CDN is something we can either pull out of data that we've already gathered from boomerang, or something we can calculate with a simple and not terribly incorrect formula:
\[
L_C = 4 \times \frac{distance\left(U \leftrightarrow C\right)}{c_{fiber}}
\]
Where \(c_{fiber}\) is the speed of light in fiber, which is approximately \(2 \times 10^8 m/s\).
DNS latency is a tough number, but since most people are fairly close to their ISPs, we can assume that this number is between 40-80ms. The worst case is much higher than that, but on average, this should be correct.
The last number we need is \(L_S\), the time it takes for the server to generate the page. This is something that we can determine just by hitting our server from a nearby box, which is pretty much what we do during development. This brings us to the tool we use to do all the calculations.
YSlow already analyses a page's structure and looks at the time it takes to download each resource. We just pull the time out from what YSlow already has. YSlow also knows the size of all resources (both compressed and uncompressed), how many domains are in use and more. By sticking these calculations into YSlow, we could get a number that a developer can use during page development.
The number may not be spot on with what real users experience, but a developer should be able to compare two page designs and determine which of these will perform better even if they get the same YSlow score.
Naturally this isn't the end of the story. We've been going back and forth on this some more, and are tending towards more of a CPM approach to the problem. I'll write more about that when we've sorted it out.
For now, leave a comment letting me know what you think. Am I way off? Do I have the right idea? Can this be improved upon? Is this something you'd like to see in YSlow?
I'm subscribed to a considerable number of RSS feeds, and so far I actually used
to read them all on my Nokia N810, which is more or less permanently located at
the bedside table
Now I wanted to import all the subscriptions into an Android RSS feed reader on
the Galaxy S. Unfortunately the feed reader that I found most useable doesn't
have OPML import. However, looking at its sqlite3 database for feed
subscriptions, it was pretty easy to come up with a small perl script to
generate "INSERT" statements for all the feeds from the N810 OPML file. In
case anyone is interested, the script is available from here.
If you have any suggestions on a good Android RSS reader that can manage large
number of subscriptions and put them into a tree/hierarchy of groups, feel free
to let me know.
Ever since I got myself an Apple iPad (64GB, Wifi only) in early April, people have been asking me why I bought it, and how I use it. These questions just got more common once people saw me on the NDTV techlife awards, with the iPad glued to my hand. And since Twitter is such a “smoke puff in a hurricane” medium, people keep asking the same questions over and over again – enough for me to put together this blog post. Which has been languishing for a while now, until Kishore Bhargava, who was also putting together a rather broader post about iPad usage, pinged me and asked me for inputs. I’ll update this post and link to his when he publishes it.
1. Why did you buy an iPad?
Short answer: My name is Atul Chitnis. That should completely and comprehensively answer your question.
Long answer: I have, for several years now, been studying and talking about the concept of The Next Billion Users – people without a PC/Mac background using technology the way we use our wristwatches (we don’t think of our wristwatches as “portable time computing devices”, do we?) and who have consciously stayed away from PC/Mac-type of devices, because they are “computers”.
I have been gathering information that I can share with developers who need to target this new audience – you wont believe how hard it is for a developer with a PC background to wrap his brain around the concept of “technology for non-technology-users”.
The iPhone, the iPod Touch and now the iPad (and soon to come iTV) all address this audience, not the lemming-like PC (or even Mac) crowd.
So I got myself an iPad in early April 2010 for one primary reason: I assumed that the iPad would represent a tipping point, and I needed to be able to understand it and its use by The Next Billion Users.
Oh, and it seemed like a fun device.
Both points proved to be right.
2. What do you primarily use the iPad for?
Short answer: to feed Steve Jobs.
Long answer: I don’t use it as a notebook replacement. I don’t even use it as a computer. In fact, the second someone suggests that I “try this great ssh app for the iPad”, my hackles stand up. I do have a few “computing tools” on the iPad, but I deliberately bury them on one of the screens.
I don’t do wordprocessing, I don’t do spreadsheets, I don’t create presentations. I barely create email, though I do use it for reading mail.
And I don’t take my iPad to client meetings (it distracts too much and wastes time – for that kind of work, I prefer a notebook, or a USB stick with my stuff on it).
I know that many people actually acquire the iPad for “zap value”, but the iPad isn’t a one-to-many device, it is a personal device, and though it does have a VGA out adaptor, that is defeating the purpose of the device.
I use the iPad the way I expect The Next Billion Users will use it – as a personal content consumption device, without consciously doing so.
Since I got the iPad, I have watched children, grand-dads, housewives and other people (who wouldn’t use a PC/Mac even if someone held a gun to their heads) take to the iPad like fish to water.
Clearly, Apple is onto something that the others are missing, and I want in on that.
3. What are some of the apps you use often?
Short answer: Steve Jobs ain’t gonna starve.
Long answer: I have 200+ apps on my iPad, and at least 600 more on my mac, downloaded over time.
I have been an iOS user since 2008 (ever since the concept of iOS apps and the AppStore kicked off), and I have been downloading (and often paying for) apps for ages. Since all these apps also work on the iPad, I naturally had a good selection to start off with when I got my iPad.
Some of the more common ones I use:
Safari, Email. iPod, Maps, Photos, Youtube and Videos: Built-in apps I can’t do without. In particular I use Videos to watch video podcasts (will make a separate post about that) and movies, especially when I am on the move.
iBooks: I have been reading eBooks since the mid 90′s, and hence have a HUGE collection of ebooks. Using Calibre, it was a cinch to convert them to ePub format and install them in iBooks. I think that iBooks could be done a whole lot better, but it (along with the Kindle app) is a usable way to read books.
Last.fm: LAST.FM client (only available in US, UK & DE appstores)
Kindle: I own a couple of physical Amazon Kindles, and honestly – I prefer those for reading books. But in a crunch, the Kindle app lets me read them as well.
Facebook: I don’t actually use the Facebook app for iOS on the iPad, because it isn’t native iPad, and in any case, the iPad is big enough to simply use the Facebook site in the browser. Not that I use Facebook that much.
MindNode: A very nice mindmap tool that I also use on my Mac, but it makes much more sense on the iPad. I use mindmaps a lot while brainstorming, so this tools gets heavily used.
Goodreader: The Swiss Army Knife of PDF reading and file management.
Pulse: RSS reader par excellence.
Mundu IM, Mundu Radio, Spokn and Mundu SMS: Instant Messaging, Internet Radio, Voice over IP and SMS apps from Geodesic.
Air Video: Let’s me watch videos stored on a computer on the network, with on-the-fly conversion. I’d rate this one as one of the top apps I use. Also great for converting AVI/MKV/etc to iPad/iPhone/iPod compatible m4v format.
SimpleNote: A simple note taking app that syncs to the web, and has clients for almost any device and OS. Once I make a note with it, it is available on any of my devices.
Toodledoo: Great ToDo app, with lots of bells and whistles. Replaced Things on my iPad after the Things author tried to gouge his iPhone customers.
Echofon: I have tried other twitter clients, but until Twitter/Tweetie for iPad comes out (its a iPhone-only app now), this is my top client that I also use on my iPhone.
We Rule: Think Farmville for the iPad – but no Facebook required
Angry Birds: Terribly addictive game!
Scrabble: Fantastic version of this game, and even lets you use your iPhones & iPods as “tile racks”.
Mahjongg 2 HD: What can I say – I am a Mahjongg addict. It calms me and provides me endless hours of gameplay.
Myst: If I have to tell you what Myst is, then you probably are not much of a game-player Technically a PC game, but makes far more sense on a toouch device like the iPad.
Bejeweled 2: Bejewelled has been on my mobile devices since the 90′s. Hopelessly addictive.
Cool Hunting: Find and read about cool stuff in art, tech and other things.
Nimbuzz: An all-in-one IM app that also does VoIP. I use it rarely (I use Mundu IM and Spokn far more) but keep it around to troubleshoot connections or the rare time that I use Yahoo Messenger.
Billings: I am a professional consultant. Tool of my trade.
Idea Sketch Another mindmap-kind of app. Rarely used, but useful as an outliner.
MagCloud: A great app for discovering magazines on the net.
ITC Mobile: Apple’s app to track AppStore sales.
Amazon.com: I have to tell you what Amazon.com is????
houzz: Heavily used (along with similar apps) during the design and construction phases of my house.
WebMD: OK, so we all have our little hurts and aches. This one lets me at least figure out the possible issues.
Firefox Home: Syncs my Firefox bookmarks and other info (including open tabs) with my other devices
Clockradio: Nice app to show me a clock and play internet radio when I am not using the iPad.
Dropbox: Really – I need to tell you what Dropbox is?
Setlist: App to show me songs in a setlist while I am practicing guitar, also lyrics and other useful info.
iBanner HD: Great app for running LED banners. Good for telling people on stage that they should hurry up and finish, so we can go have food.
VNC: The only PC centric app – used to access my Macs and other VNC-capable devices.
Google Earth: Fantastic version of Google Earth for the iPad.
iDraft: Great sketching app. Especially nice for simulated press-sensitivity and variable thickness on the fly.
Epicurious: A gorgeous cookery book.
Aquarium: Does nothing but show fish in an aquarium, but the sound makes people rush to the bathroom
Many of these apps also exist on the iPhone and I use them there as well.
Note that I also bought and have installed Pages, Numbers and Keynote for the iPad, but I don’t use them for anything but demonstrating them to people who want to know about them
This is far from a comprehensive list, and keeps changing as I discover new apps. Unfortunately, no one has written an AppList kind of application that looks at all installed apps, looks them up on the appstore and creates an exportable document that lists the apps, descriptions and frequency of use. (Hint, that’s an app idea you could exploit!)
Recently in the last month, I traveled to Bhutan to attend the SANOG Conference. Bhutan is a small country nestled in the Himalayan mountains surrounded by Indian to the East, West and South and China to the North. It was a good opportunity to meet some like-minded network geeks and also visit an exotic country.
The 16th edition of SANOG was held in Paro, Bhutan. This was the second time that Bhutan was hosting SANOG. SANOG was held in the the Paro Engineering College beside the Paro river in very picturesque settings. The earlier edition of SANOG in Bhutan was held in the capital, Thimphu. This was the 2nd time I was attending SANOG, having attended an earlier edition of SANOG in Mumbai in 2006.
I attended the workshop on Network Security by Gaurab Raj Upadhyay and Johhny Martin from PCH. It covered the basics of security specifically for ISPs and large network providers. There were some good discussions on how to manage the different security audit process as well as an incident management program in case of network security breaches. The hands-on part of the workshop concentrated heavily on securing backbone routers and exchanging routes information securely. Some aspects of filtering and verifying network traffic were also covered. The last day had demos of several tools such as nessus and nmap. The slides can be downloaded from the SANOG Program page. Also in between the workshop breaks and during one of the days of the workshop, Devdas and I wrote a improved whois server that is hopefully in production now at the NIC website.
In the tutorials part of SANOG, I was giving a half-day tutorial on application-level performance measurement [Slides,PDF]. There was an small but interested crowd in the tutorials. I ended up covering a lot more of the web-facing and measurement tools as many of the participants were application developers who had written quite a bit of PHP code. It was the first time I was giving a tutorial on this topic and it helped that it was interactive. In addition to the material on the slides, I talked a bit about front-end performance and tools such as Yslow (Yahoo), Pagespeed (Google) and Webpage Test (AOL). There was a lot of whiteboarding and veered a little away from the slides. I also spoke about the network measurement work being done in the IPPM, BMWG and PMOL working groups in the IETF. The feedback was pretty good and I plan to give a longer version tutorial at later versions of SANOG/APRICOT. I skipped the second day of the tutorials and went to Chele La pass.
The conference had several talks that I was looking forward to and I was not disappointed. The standout talk were on long distance wireless network deployment by Matt Peterson and F-root update by Pete Losher. Both has interesting networking insights and interesting traffic data. I also gave a talk on my IETF fellowship experience [Slides,PDF]. Some of the slides were liberally lifted from “The Tao of the IETF” written by Paul Hoffman. As (good) luck might have have it, I ran into Paul Hoffman at the IETF 78 and told him about it . There were a few questions about the fellowship after the conference so I hope it would inspire more people to apply to the IETF fellowship.
Shame on the government for the arrest of security researcher, Hari Prasad, see USENIX letter. It looks very likely that the Election Commissioner, SY Quraishi's claims that the electronic voting devices are tamper-proof are totally bogus. I've always wondered whether a true majority of people were really voting in such obviously corrupt politicians like the Maino mafioso family, well, now we
@palewar sry nothing planned – in fact most of the pictures I post ths days R just taken on morning walks, but he an come & meet anytime in reply to palewar#
According to several sources such as indianevm.com, Hari Prasad was
being arrested. He is part of a team of IT security researchers that gathered
evidence to demonstrate how incredibly weak the security of India's voting
machines is. For more details, read the indianevm.com article linked above,
and the various quotes/links in it.
This is very upsetting. They should jail those who have authorized the
deployment of such an insecure system in the first place. Those are the people
responsible - not some researchers who go out of their way to uncover the
technical problems to warn the general public about the inherent risks of
this technology.
I sincerely hope that the authorities will understand the grave mistake
they're doing here. Don't shoot the messenger. It's not his fault
that engineer, engineering management and/or regulatory government
authorities have permitted such a system in the first place.
Last year, at FOSS.IN, the Raghu Dixit Project performed during the event closing ceremony. People went nuts with delight.
Sadly, no video of the show exists, but Raghu recently performed in London, as part of a wildly successful UK tour, and the BBC filmed it and put it up! And here it is, straight from the BBC site:
I recently read the book The Checklist Manifesto by Atul Gawande – a respected surgeon, noted author, MacArthur fellow, New Yorker staff writer, and a professor at Harvard Medical School.
The premise of the entire book is the author’s dive into the concept of a checklist and how they have dramatically improved the efficiency and reliability of professionals in the medical profession, the aeronautical industry, the architecture industry and even the venture capital industry.
So what is a checklist? It is the minimum set of critical steps for any task to be achieved.
Why are they useful? Because checklists protect against many kinds of dangers. For example:
“Faulty memory and distraction are a particular danger in what engineers call all-or-none processes – if you miss just one key thing, you might as well not have made the effort at all (whether it is buying ingredients for a cake or preparing an airplane for takeoff).”
“People can lull themselves into skipping steps even when they remember them. Especially in busy and stressed workplaces (such as hospitals). In complex processes, certain steps don’t always matter, may be it affects only 1 out of 50 times. But when it does, it can be catastrophic.”
One of my favorite passages in the book is as follows (it’s a longer excerpt than I would have liked, but all the parts were really important, so please read the whole passage to understand what’s going on):
Checklists remind us of the minimum necessary steps and make them explicit. They not only offer the possibility of verification but also instill a kind of discipline of higher performance. Which is precisely what happened with vital signs – thought it was not doctors who deserved the credit.
The routine recording of the four vital signs did not become the norm in Western hospitals until the 1960s, when nurses embraced the idea. They designed their patient charts and forms to include the signs, especially creating a checklist for themselves.
With all the things nurses had to do for their patients over the course of a day or night – dispense their medications, dress their wounds, troubleshoot problems – the “vitals chart” provided a way of ensuring that every six hours, or more often when nurses judged necessary, they didn’t forget to check their patient’s pulse, blood pressure, temperature and respiration and assess exactly how the patient was doing.
In most hospitals, nurses have since added a fifth vital sign: pain, as rated by patients on a scale of one to ten. And nurses have developed yet further such bedside innovations – for example, medication timing charts and brief written care plans for every patient. No one calls these checklists but, really, that’s what they are. They have been welcomed by nursing but haven’t quite carried over into doctoring.
Charts and checlists, that’s nursing stuff — boring stuff. They are nothing that we doctors, withour extra years of training and specialization, would ever need or use.
In 2001, though, a critical care specialist at Johns Hopkins Hospital named Peter Pronovost decided to give a doctor checklist a try. He didn’t attempt to make the checklist encompass everything ICU teams might need to do in a day. He designed it to tackle just one of their hundreds of potential tasks, the one that nearly killed Anthony DeFilippo: central line infections.
On a sheet of plain paper, he plotted out the steps to take in order to avoid infections when putting in a central line. Doctors are supposed to (1) wash their hands with soap, (2) clean the patient’s skin with chlorhexidine antiseptic, (3) put sterile drapes over the entire patient, (4) wear a mask, hat, sterile gown, and gloves, and (5) put a sterile dressing over the insertion site once the line is in. Check, check, check, check, check. These steps are no-brainers; they have been known and taught for years. So it seemed silly to make a checklist for something so obvious. Still, Pronovost asked the nurses in his ICU to observe the doctors for a month as they put lines into patients and record how often they carried out each step. In more than a third of patients, they skipped at least one.
The next month, he and his team persuaded the Johns Hopkins Hospital administration to authorize nurses to stop doctors if they saw them skipping a step on the checklist; nurses were also to ask the doctors each day whether any lines ought to be removed, so as not to leave them in longer than necessary. This was revolutionary. Nurses have always had their ways of nudging a doctor into doing the right thing, ranging from the gentle reminder (“Um, did you forget to put on your mask, doctor?”) to more forceful methods (I’ve had a nurse bodycheck me when she thought I hadn’t put enough drapes on a patient). But many nurses aren’t sure whether this is their place or whether a given measure is worth a confrontation. (Does it really matter whether a patient’s legs are draped for a line going into the chest?”) The new rule made it clear: if doctors didn’t follow every step, the nurses would have backup from the administration to intervene.
For a year afterward, Pronovost and his colleagues monitored what happened. The results were so dramatic that they weren’t sure whether to believe them: the ten-day line-infection rate went from 11 percent to zero. So they followed patients for fifteen more months. Only two line infections occurred during the entire period. They calculated that, in this one hospital, the checklist had prevented forty-three infections and eight deaths and saved two million dollars in costs.
If that, my friends, does not explain the power of a simple checklist, I don’t know what can.
And yet, despite these results, people were reluctant to adopt checklists. In fact, I know you are dismissing the idea right now. Try writing down 5 reasons why checklists are stupid and won’t work for you. Now write 5 reasons why it will work. Think over it. I bet most people find the 5 reasons against checklists, easier to write, but will be convinced about it after writing the 5 reasons for it.
Personally, I have been drilled into the idea of checklists thanks to the GTD Weekly Review. Since I use a checklist once a week, I started making checklists for the routine yet essential parts of my life, from organizing things around the house once a day to a preparation checklist for trekking.
I am trying to think of ways that checklists can apply to IT and software development. I guess we already have it in many ways – whether (1) in the form of Agile / Scrum / XP methodologies, or (2) in the form of code reviews (verification is outsourced to another human who has to run through the checklist manually), or (3) in the form of automated test suites (verification is automated).
But we seem to resist these checklists (as detailed in the book in other contexts including the venture capital industry), we think “Oh, I’m too professional for such a methodology” or “Pfft, it’s a waste of time, I just want to code.” I have been guilty of it many times as well.
And at the same time, I had not imagined that checklists can be used for ensuring communication to all the concerned parties.
Let me take an excerpt from Atul Gawande’s exploration of the architecture field in the book:
It is unnerving to think that we allow buildings this difficult to design and construct to go up in the midst of our major cities, with thousands of people inside and tens of thousands more living and working nearby. Doing so seems risky and unwise. But we allow it based on trust in the ability of experts to manage the complexities. They in turn know better than to rely on their individual abilities to get everything right. They trust instead in one set of checklists to make sure that simple steps are not missed or skipped and in another set to make sure that everyone talks through and resolves all the hard and unexpected problems.
“The biggest cause of serious error in this business is a failure of communication,” O’Sullivan told me.
In the Citicorp building, for example, the calculations behind the designs for stabilizing the building assumed the joints in those giant braces at the base of the building would be welded. Joint welding, however, is labor intensive and therefore expensive. Bethlehem Steel, who took the contract to erect the tower, proposed switching to bilted joints, which are not as strong. They calculated that the bolts would do the job. But, as a New Yorker story later uncovered, their calculations were somehow not reviewed with LeMessurier. That checkpoint was bypassed.
It is not certain that a review would have led him to recognize a problem at the time. But in 1978, a year after the building opened, LeMessurier, prompted by a question from a Princeton engineering student, discovered the change. And he found it had produced a fatal flaw: the building would not be able to withstand seventy-mile-an-hour winds – which, according to weather tables, would occur at least once every fifty-five years in New York City. In that circumstance, the joints would fail and the building would collapse, starting on the thirtieth floor. By now, the tower was fully occupied. LeMessurier broke the news to the owners and to city officials. And that summer, as Hurricane Ella made its way toward the city, an emergency crew worked at night under veil of secrecy to weld two-inch-thick steel plates around the two hundred critical bolts, and the building was secured. The Citicorp tower has stood solidly ever since.
The construction industry’s checklist process has clearly not been foolproof at catching problems. Nonetheless, its record of success has been astonishing. In the United States, we have nearly five million commercial buildings, almost one hundred million low-rise homes, and eight million or so high-rise residences. We add somewhere around seventy thousand new commercial buildings and one million new homes each year. But “building failure” – defined as partial or full collapse of a functioning structure – is exceedingly rare, especially for skyscrapers. According to a 2003 Ohio State University study, the United States experiences an average of just twenty serious “building failures” per year. That’s an annual avoidable failure rate of less than 0.00002 percent. And, as Joe Salvia explained to me, although buildings are now more complex and sophisticated than ever in history, with higher standards expected for everything from earthquake proofing to energy efficiency, they take a third less time to build than they did when he started his career.
The checklists work.
The lesson learned for me is that the book repeatedly showcases how simple checklists ensure that we get the basics right, which ultimately means we develop more trust in the ecosystem that things will happen (whether humans trust other humans more, or whether humans trust more in a system or process, or whether we trust ourselves more), and when that trust and stability is established, we go on to greater heights.
Let me give you an example to illustrate what I am thinking about – the trust factor also applies to any “productivity system” that you create for yourself, no matter how simplistic or naive. Until you develop trust in that system that it works and there are no major holes in the system, you will never trust the system enough to make it succeed, and ultimately you will sabotage yourself and your productivity system breaks down. This is one of the reasons why the Weekly Review is the secret sauce of the GTD methodology – if you review once a week, you can quickly build trust in your system that you are taking care of all that is important to you.
And, don’t forget that the Weekly Review is a checklist. And this is exactly why you probably need more checklists in your life.
So what are the checklists that you think you should have in your work life and personal life? I’m curious to hear, so looking forward to your comments.
P.S. I have taken the liberty of such long excerpts from the book in this blog post, because these two excerpts are from only the first 80 pages of the book, there are many more gems in the book (like the story of Hurricane Katrina and Walmart and the lesson of decentralizing decision making using checklists), if you’re interested, you should definitely go buy the book.
For many years I'm on a more or less consistent hunt for finding a
reasonably open and free mobile phone. This started in 2004 with OpenEZX,
has continued with Openmoko, project gnufiish and has resulted in a bit of
peeking and poking in the Palm Pre. However, none of those projects ever had
the success I was hoping for:
OpenEZX was never really finished, and only for the 1st generation phones (A780) by the time they were long end of life
OpenMoko Neo1973 and FreeRunner were a great project, and they are still the most open+free mobile phones that ever existed. However, they're GPRS only and the hardware is even more outdated now then it was when we created it.
gnufiish was an attempt of running software from the Openmoko days (such as freesmartphone.org) on some E-TEN glofiish phones. However, we never could make the SPI-based modem communication work from our re-engineered Linux driver :(
Palm Pre is an interesting device, in that Palm provides easy root
access, does not attempt to lock the device down with cryptographic signatures
and provides full recovery flashing tools by means of WebOS Doctor. But once
again, the proprietary communication protocol with the 3G Modem was the big
blocker item for using real custom software and not the WebOS stuff they ship.
So I've constantly been on the watch for new devices that are coming out. Most
of the phones you can buy in recent years are either running proprietary
software like Windows Mobile, Symbian, Apples iPhone-OSX - or they run Android
but then use some integrated Qualcomm Smartphone-on-a-chip product. The
problem with the latter (from a Free Software point of view) is that Qualcomm
is very secretive about their products, does not provide any kind of public
documentation, and the ever-increasing integration between application
processor and baseband processor makes it more difficult to run custom software
on them.
The Samsung Galaxy S (GT-I9000) seemed like a good candidate to me, for several
reasons:
Samsung does not use cryptographic signature techniques and gaining root as well as flashing the AP software is relatively easy
The phone is based on a traditional separate application processor (AP) and
baseband processor (BP) design. The AP is a Samsung S5PC110, the BP is some
Qualcomm MSM6xxx.
High-end hardware, with the S5PC110 running at 1GHz and 512MB RAM
Samsung provides excellent "GPL source code offers" containing the Linux
kernel used in their firmware - including detailed instructions in how to build
it. Also, many of the drivers are included under GPL, such as drivers for all
the integrated peripherals of the SoC, some custom components like the USB
multiplexor ASIC, etc. as well as the driver for the dual-ported RAM between
the AP and BP for the 3G Modem communication
The Android RIL shipped by Samsung contains lots of debugging/decoding/dumping
code that can make reverse engineering the AP/BP protocol.
So right now I'm in the exploration phase, making myself familiar with the
bootloader, the flashing process, the userspace ABI of the custom (GPL
licensed) kernel drivers, etc. It's a fairly pleasant experience so far,
and I now have a debootstrap'ed Debian lenny on an additional ext2 partition
on the SD card. This provides me with an actually useful userland I can
chroot() into, such as lsof, strace, ltrace, tcpdump, etc. to do some more
exploration of the phone.
The only real ugliness on the software side so far is the use of proprietary
Samsung filesystems (RFS/TFS4). The only reason those filesystems existed,
as far as I can tell, was to run legacy filesystems like FAT on top of raw NAND
or OneNAND flash. This is mainly necessary if you want to export e.g. a FAT
partition via USB Mass Storage to a Windows PC. However, the GT-I9000 doesn't
have any OneNAND, but only an internal moviNAND (basically a SD-Card in a BGA
package that you can solder on the board). MMC/SD cards already include the
wear leveling algorithm, so there is absolutely no point (from what I can tell)
in running the RFS/TFS4 stack.
In fact, in several forums people are complaining about the slow I/O performance
of the Galaxy S, and they have a much better performance when using ext2/ext3
directly on that moviNAND device.
It took me a while to figure this out for all the OSes I use. The only solution I found for MacOSX was hidden inside a post about installing extensions globally.