Category Archives: stories

CS in Schools: September Update

CS in Schools is a not-for-profit initiative at RMIT University that’s focused on helping high school teachers develop their confidence and competence in teaching computer science.

September was our third month out of stealth mode. Since our last update, we’ve formally joined forces with RMIT and advertised for teachers to join our programme. Please share this link with teacher colleagues, friends, and anyone who might want to work with us.

We signed up an eighth school into our free pilot, and we’re at capacity for 2019. We’re now deep in the logistics of timetabling, resourcing, and planning.

Woman Programming on a Notebook

Summary

CS in Schools is part of RMIT‘s Policy and Impact Portfolio. It’s a charity initiative that’s focused on helping teachers confidently teach computer science to high school students in Australia.

Today, most schools struggle to teach coding: there’s a shortage of teachers who feel qualified to teach computer science, and most successful coding classes are run outside of school hours. We believe that today’s teachers can effectively teach coding if they’re supported through in-class professional development. Microsoft’s TEALS programme exists in the US, and we want Australian teachers to have a similar opportunity.

Many of the important and best paid jobs of this and the next generation will require computational thinking. Even if a student doesn’t study computer science at university, it’s essential they have the basics because just about every job will be changed by technology. We want every student in Australia to have this opportunity.

In 2019, we are piloting a programme with eight schools, and studying how successfully we can help teachers ramp-up their skills. Beyond 2019, we plan to launch this programme broadly.

We’ve had an exciting September. In summary, in the past month:

  • We named ourselves CS in Schools, and bought the domain csinschools.io. You can now contact us at hugh@csinschools.io and selina@csinschools.io.
  • We’ve signed-up our eighth school into our 2019 pilot, and we’re at full capacity
  • We’ve become part of RMIT University, giving us access to resources, educators, facilities, and enabling us to become a Tier 1 DGR charity (an important Australian tax status)
  • We’ve advertised for teachers to work with us
  • We’re refining a roadmap for what happens from now until we start the programme in February

To learn more about our programme, see the “Programme” section in our August update.

September Update

September was another terrific month for our programme: it’s all coming together, and building momentum towards our 2019 pilot.

This month, we formally joined RMIT University. We’re now part of the Policy and Impact Portfolio, and have an office inside RMIT’s Activator space. RMIT’s generosity has been amazing: they’re providing offices, finance support, HR and legal support, and support for philanthropic engagement. Of course, being part of RMIT also gives us enormous credibility and opens all kinds of doors. We thank Vice-Chancellor Martin Bean and his team for their kindness and support in helping CS in Schools take a leap forward.

We finalised the schools that we’ll be working with in our pilot in 2019. These are:

It’s likely that somewhere between 10 and 15 teachers will be trained through our programme next year, and over 1,000 Year 7 students will experience our course. We’re excited to be able to study the outcomes of the programme, and hopefully scale it in 2020.

We are working hard on finalising financial support for 2019. After building our draft timetable and revising our budget, we could do with more money. If you have corporate connections or connections to philanthropic donors, we’d love an intro!

We are now hiring teachers. We plan to hire up to three qualified high school teachers who have experience teaching computing. Our job ad is live, and here’s a link to the position description. Please share it broadly with your colleagues, family, and friends who might be interested. Hopefully, in our next update, we can share the news of who we’ve hired, and have made progress on developing our lessons.

The final news from the month is that we’re getting closer to Microsoft’s TEALS programme. Kevin Wang at Microsoft leads this initiative, and he’s been generous in sharing his time to help us learn about onboarding schools, curriculum development, and structure of their engagement with volunteers, schools, and universities. Under an NDA between RMIT and Microsoft, we’ve recently been able to access their materials, and this has helped us not reinvent the wheel from first principles. We hope to further deepen our TEALS engagement over the next month.

Thanks again for making it all the way to the bottom of the update. Let us know if you’d like to learn more about any topic. Cheers, Hugh and Selina.

 

 

Guillain–Barré syndrome

I suffered from Guillain–Barré Syndrome (GBS) in 2009.

I am now perfectly healthy, and I’m on a mission to raise money for the GBS/CIDP Foundation. I’m going to do what GBS stopped me doing for a while: running! I’m going to run 52 races this year. Please join me in helping others who suffer from these terrible conditions by doing four things:

  1. Liking my fundraising page on Facebook
  2. Following my fundraising on Twitter @fiftytwofives
  3. Reading my fundraising and running blog at http://fiftytwofives.com
  4. By donating at IndieGogo. Every dollar counts — there’s cool perks available!

Now, here’s the story…

The Short Story

One day in the middle of 2009, I woke up to a tingling sensation in my toes, almost like a cramp that made them feel like they were curling. I was a little dizzy.

Over a couple of days, more strange sensations began in my legs and eventually my arms. My heels went numb, then my toes, and then my calves started tingling and went mostly numb too. I felt strange buzzing sensations in my legs. Walking was awkward. My face started feeling a little numb, and talking felt strange. I suddenly felt exhausted just walking to the mailbox. I was freaked out. Very freaked out.

Late in 2009, a few months after I was diagnosed with GBS. I'm out of shape, but on my way to recovery

Late in 2009, a few months after I was diagnosed with GBS. I’m out of shape, but on my way to recovery

My general practitioner didn’t know what was happening, and sent me to a neurologist.

The neurologist tried some reflex tests. A hammer-hit on the knee did nothing. I normally had good reflexes. I had a few other tests, including getting to know the inside of an MRI machine pretty well. Somewhere around this time, doctors started muttering possible diagnoses such as Multiple Sclerosis. I wouldn’t wish that undiagnosed limbo on anyone.

The next step was a visit to the UCSF Medical Center, where I was finally but quickly diagnosed with Guillain-Barre Syndrome (GBS). While I wasn’t happy to be sick, I was very happy to know what the problem actually was, and to learn more about the condition. I’ll come back to that in a moment.

It was a tough time. My family was in Seattle, and I was in California. I’d just started a new job at eBay. Luckily, eBay was very understanding, and I was able to quietly work part-time for a while. My days went like this: wake up at 8am, feeling exhausted; struggle to make breakfast; slowly get ready (lots of sitting and resting); drive to work; pretend you’re ok for a few hours (while sitting, resting, and feeling strange sensations); go home; struggle to make a meal; sleep for 13 to 15 hours; begin the next day.

What is GBS?

GBS is rare and unusual. It occurs in one to two people per 100,000.

It’s thought that after you’ve had an infection (in my case, probably a viral ear infection), your immune system loses the plot and attacks your nervous system. GBS is otherwise known as Acute Inflammatory Demyelinating Polyneuropathy (AIDP) which gives you clues as to what it does. Acute means it’s not as serious as it could be; chronic is worse. Demyelinating means your immune system strips your peripheral nerves of their myelin, leading to strange sensations and loss of function. Polyneuropathy means it affects many nerves at once. It perhaps should be called Peripheral AIDP since it doesn’t affect your central nervous system (brain and spine): it starts at your feet and works its way up, often taking out your arms.

Serious cases leave people on a respirator and can involve months in hospital. My case wasn’t serious. There’s no cure for GBS – you just wait it out. Doctors often prescribe strong steroids, but there’s no evidence I can find that they help. Blood transfusions can ease the symptoms. Luckily, most people are back to normal within a year or two. Not everyone is that lucky though.

People who’ve suffered from GBS have the same chance of getting it again as those who’ve never had it.

For the Australians out there, you may recall that Alistair Clarkson, the coach of the Hawthorn footy club had GBS in May 2014. He recovered quickly and, of course, coached the Hawks to the flag (championship). Other notable folks who’ve had GBS include Franklin D. Roosevelt, Joseph Heller, Andy Griffith, and Lucky Oceans.

Getting Better

Over the next year, I put on 25+ pounds and became horribly out of shape. There’s no way I could exercise, and I wasn’t in the mood to eat right. I often woke in the night because of numb hands and tingling legs. I was phenomenally tired and easily exhausted. My balance was off, and I became dizzy easily. But I steadily got better – and by mid 2010 was thinking about getting gently back into exercise. Fast forward to today and I’m completely fine.

A recent race. I'm back running, and ready to run 52 races in 2015 to fight GBS

A recent race. I’m back running, and ready to run 52 races in 2015 to fight GBS

I think differently post-GBS. I know that health is the most important thing in the world: without it, you can’t look after your family, let alone work. I spend more time looking after myself, and balancing work and life more effectively. I also think more about people less fortunate than me: having GBS was tough, but my case was mild and there are far worse things that happen to people.

Helping People with GBS

I am turning the tables on GBS, and fundraising for the GBS/CIDP Foundation. I am going to run fifty-two races in 2015, and blog about it over at fiftytwofives.com. The name is inspired from running fifty-two races of 5k in distance — but I will count anything that has a timer as one race (one-milers, 5ks, 10ks, ten-milers, half-marathons. Heck, maybe even a marathon). If you’d like to be part of my fundraising, just head over here to IndieGoGo.

The GBS/CIDP Foundation is doing great work. The foundation helps with education for those suffering GBS and its chronic, recurring cousin CIDP and related conditions. They fund research to understand more about this condition. They lobby to ensure people get access to the health care they need (I’m lucky because I can afford access to great healthcare; of course, not everyone can).

A Quirky Afterword

Next time you have a flu vaccination, take note of the questions you’re asked. Down the bottom, you’ll find “Have you ever suffered from GBS?”. If you answer yes, your doctor probably won’t give you the flu vax – in 1976, after the flu vax was issued, there was roughly twice the incidence of GBS in people who’d had the vax compared to the population that hadn’t. It’s not understood why that happened. And even though they think GBS doesn’t recur, they generally won’t give the flu vax to folks who’ve had GBS.

I didn’t get the flu vax for that reason from 2009 to 2013. However, after I got the flu in 2013, I talked my doctor into giving me the flu vax in 2014. I just got this year’s too. Nothing interesting happened. I’m happy about that.

I thank Sean Southey for encouraging me to share my GBS story.

See you next time.

It’s a Marathon, not a Sprint…

What makes a career successful over the long term? How do you sustain (or even increase) your professional impact, while also deriving meaning and enjoyment from your life? This was the question I set about answering in my talk at StretchCon last week. To see my answers, you can watch the presentation. You can also view the prezi1966321_313990785474109_1977531760847682083_o

The Backstory

I asked eleven colleagues about their success. I chose colleagues who have made it to the C-suite (whether as a CEO, CTO, or another C-level designation) and that appeared to do it with balance between their professional and personal lives. Ten of the eleven responded, and nine of the ten shared thoughts before my deadline. I thank Chris Caren, Adrian Colyer, John Donahoe, Ken Moss, Satya Nadella, Mike Olson, Christopher Payne, Stephanie Tilenius, and Joe Tucci for their help.

I sent each of these colleagues an email that went something like this:

I am speaking about successful careers being about sustained contribution (and not a series of sprints, all-nighters, or unsustainable peaks). Would you be up for giving me a quote I could use and attribute to you? I admire your ability to work hard and smart, while obviously also having a life outside of work.

Their replies were varied, but as you’ll see in the video, there were themes that repeated in their answers. I shared edited quotes in the talk, and promised that I’d share their complete thoughts in my blog. The remainder of this blog is their complete words.

Chris Caren

Chris is the CEO and Chairman of Turnitin. We worked together at Microsoft, and Chris was (and sometimes still is!) my mentor. Here are his thoughts in response to my questions:

My philosophy:  I do my best work when my life is in balance — family, me, and work.  I need a routine of hard work, but no more than 9-10 hours a day, solid exercise daily, low stress (via self-control), 7-8 hours of sleep at a minimum each day, and the time I want with my family and for myself.  When I maintain this balance, I am maximally effective at work — both in terms of quality of thinking and decision making, and maximum output.  More hours worked actually pull down my impact as a CEO.

Adrian Colyer

Adrian was the CTO of SpringSource, the custodians of the Spring Java programming framework. We worked together at Pivotal, where he was the CTO of the Application Fabric team. Recently, Adrian joined Accel Partners as an Executive-in-Residence. Here are Adrian’s thoughts:

A great topic! Maybe the most counter-intuitive lesson I’ve learned over the years is that I can make a much more valuable contribution when I work* less. So work-life balance isn’t really a trade-off as most people normally present it (I have more ‘life’, but sacrifice ‘work’ to get it), it’s actually a way of being better at both life *and* work!

* ‘work’ in the sense that most people would intuitively think of it – frenetic activity.

When I’ve analysed this, I came to realise that when work crowds everything else out I often end up in a very reactive mode. But the biggest and most impactful things you can do – especially as a leader – don’t come about during that constant fire-fighting mode. The vast majority of my important insights and decisions – the things that made the biggest positive impact on the organisations I was working with at the time – have come in the space I’ve made around the busy-ness of the office to actually allow myself the luxury of thinking! Running, cycling, walking and so on have all been very effective for me over the years. But so is just taking some time out in the evening and not necessarily even consciously thinking about work, the brain seems to be very good at background processing! That time has also given space to allow my natural curiosity and love of learning to be indulged. In turn that creates a broader perspective, exposes you to new ideas, and allows you to make connections and insights that you otherwise might not of. All of this feeds back into the work-related decisions and issues you are wrestling with and helps you to make breakthroughs from time to time.

To the extent I’ve been successful over the years, I attribute much of that not to being smarter than the people around me, nor to working ‘harder’, but to creating the space to think.

John Donahoe

John is the CEO of eBay Inc. John was an enthusiastic sponsor of my work while I was there. When I asked John for his thoughts, he sent me a speech he’d recently given to the graduating class at the Stanford Business School. In it, you’ll find John’s thoughts of his professional and personal journey.

Ken Moss

Ken recently became the CTO of Electronic Arts. Prior to that, Ken and I worked together on, off, and on over a period of nine years. Ken was the GM of Microsoft’s MSN Search when I joined Microsoft, and left to found his own company. I managed to help persuade Ken to come to eBay for a few years. Here are Ken’s thoughts:

Always focus on exceeding expectations in the present, while keeping your tank 100% full of gas for the future. There is no quicker way to stall your career than by burning yourself out. I’ve seen many potentially brilliant careers cut short as someone pushed themselves too far past their limits and became bitter under-performers. It’s always in your control.

Satya Nadella

Satya became the CEO of Microsoft at the beginning of 2014. Satya was the VP of the Bing search team at Microsoft for around half the time I was there, and we have stayed in touch since. Here are Satya’s thoughts:

I would say the thing that I am most focused on is to harmonize my work and life vs trying to find the elusive “balance”. Being present in the lives of my family in the moments I am with them is more important than any quantitative view of balance.

Mike Olson

Mike is the Chairman, Chief Strategy Officer, and former CEO of Cloudera. We have interacted during my time at Pivotal, and also during my time at eBay. Mike was kind enough to invite me to give the keynote at Hadoop World in 2011. Here’s Mike’s thoughts:

I have always tried to optimize for interesting — working on problems that are important to me, with people who blow my hair back. The combination has kept me challenged and inspired, and has guaranteed real happiness in the job.

By corollary, you have to be willing to walk away from a good paycheck and fat equity if the work or the people are wrong. Money is cheaper than meaning. I’ve done that a few times. There’s some short-term angst, but it’s paid off in the long term.

Christopher Payne

Christopher is the SVP of the North America business at eBay. Christopher and I have worked on, off, and on for nine years. Christopher was the founding VP of the search team at Microsoft. He left to found his own company, his company was bought by eBay, he hired me to eBay to help run engineering, and he then moved over to run the US and Canadian business teams. Here are Christopher’s thoughts:

I believe strongly in the need to maintain my energy level in order to have the most impact in my career. To do this I find I have to make the time to recharge. For me this means taking walks during the work day, taking all of my vacation, and not being on email 24/7. With my energy level high I find I can be significantly more creative and productive over the long term.

Stephanie Tilenius

Stephanie recently founded her own company, Vida. While she’s spent parts of her career at Kleiner-Perkins, Google, and other places, we met at eBay where we spent around six months working together. Here are Stephanie’s thoughts:

… my point of view is that you have to do something you love, that will sustain you. You also have to know what drives you, what gets you out of bed, for me it is having an impact (for others it may be making money or playing a sport, etc.) You will always be willing to give it your all and you are more likely to innovate if you love what you are doing and constantly growing, challenging the status quo (stagnation is really out of the question, humans don’t thrive on it!). I am committed to my work and to constant innovation but also to having a family and I could not be great at either without the other. They are symbiotic in my mind, they both make me happy and a better person. I have learned it is about integration not necessarily perfect balance. If you integrate life and work, you are much more likely to be successful. The other day my son was out of school early and our nanny had an issue so I brought him to work and he did code academy and talked to some of our engineers. He enjoyed himself and was inspired.

Joe Tucci

Joe is the Chairman of EMC, VMware, and Pivotal, and the CEO of EMC. I met Joe in the interview process at Pivotal, and have worked with him through board and other meetings over the past year. Here’s Joe’s thoughts:

Being a successful CEO is relatively straight forward… 1st – retain, hire, and develop the best talent, 2nd – get these talented individuals to work together as a team (do not tolerate selfishness), 3rd – get this leadership team to embrace a stretch goal that is bigger then any of them imagine they can attain, and 4th – maniacally focus the leadership team on our customers (always striving to exceed their expectations)

I enjoyed giving the talk at Stretch, and interacting with these colleagues in putting it together. I hope you enjoyed it too. See you next time.

Learning Lessons from the Apollo program

I’m fascinated by the Apollo program. It’s a triumph of human endeavour that we sent twenty-four men to the moon, and twelve to the surface between 1969 and 1972. It was a program built with reliable 1950s-designed equipment, and computers far less sophisticated than a cheap modern wristwatch. Achieving Kennedy’s audacious vision was made possible through teamwork, planning, hard work, and ingenuity.

Recently, I decided to learn more about the early Apollo missions to understand what work went into getting us to the moon. It’s an incredibly story, and perhaps more interesting than several later missions.

An incremental approach

Apollo 7 was the first manned Apollo mission to fly in space. It was a confidence-builder, and the first time three people had flown together in space around the Earth. After eleven days in 1968, the crew returned having tested the command module and successfully made a live TV appearance.

The Apollo 7 crew during the first live broadcast from space

The Apollo 7 crew during the first live broadcast from space

The critical pieces of Apollo 7 had flown earlier. The earlier unmanned Apollo 4 and 6 had tested launching a similar unmanned command module and returning it to earth, while Apollo 5 had also tested the same Saturn IB rocket that was used to launch Apollo 7. Apollo 7 was focused on testing putting three astronauts in space in what was a now-trusted setup.

Apollo 8 was a shorter, six day mission. Three men flew to the moon, orbited it a few times, and returned to earth. They were the first to fly atop the Saturn V rocket — the smaller Saturn IB rocket used in Apollo 7 wasn’t sufficient to reach the moon. The Saturn V had been tested in Apollo 4 and 6. This was an audacious mission — testing both a manned Saturn V mission, and visiting the moon. Behinds the scenes, it was a tough sell to management — they didn’t like being that aggressive. But it made sense as a mission: the lunar module was behind in development and wasn’t ready to be tested, and there was fear the Russians might get Cosmonauts around the moon in 1968.

The far side of the moon as seen from Apollo 8. The Apollo 8 crew was the first to ever see the dark side of the moon

The far side of the moon as seen from Apollo 8. The Apollo 8 crew was the first to ever see the dark side of the moon

Apollo 9 was a return to an incremental approach. The mission orbited the earth, tested the lunar module in earth orbit (that would later be used to land on the moon), and included a space walk to test the spacesuits. It also included a rendezvous, which was necessary with the command and lunar modules being separated.

Testing the Apollo 9 lunar module Spider in earth orbit

Testing the Apollo 9 lunar module Spider in earth orbit

Apollo 10 was the full dress rehearsal for landing on the moon. It was time to repeat the test of the lunar module, but this time in moon orbit. The lunar module detached from the command module, and the crew descended to within ten miles of the moon’s surface. They then returned to rendezvous with the command module, and journeyed back to earth. In total, the crew spent eight days in space, and the mission was a huge success — so successful that Apollo 11 was the mission that met Kennedy’s goal in July 1969.

The Apollo 10 lunar module Snoopy returns from almost landing on the moon

The Apollo 10 lunar module Snoopy returns from almost landing on the moon

Interestingly, many people at NASA thought early in the Apollo program that Apollo 12 was likely to be the mission that landed first on the moon. Perhaps if Apollo 9 had happened before Apollo 8 (as was originally planned), there might have been two separate missions to test the manned Saturn V and then a manned Saturn V to the moon. Certainly, if something substantial had gone wrong between Apollo 7 and 10, Apollo 11 would have been repeating validation of the space craft, space suits, and processes.

The tortoise beats the hare

The Soviet Union went all-in with Soyuz 1. It was the first flight of the new Soyuz spacecraft and Soyuz rocket, and was planned to be a rendezvous with the three-manned Soyuz 2. The mission had problems from the start — a solar panel failed to deploy, and this delayed the launch of Soyuz 2. The weather turned bad, and Soyuz 2 didn’t launch. This was fortunate, as the parachute on Soyuz 1 didn’t deploy due to a design fault, and the single Cosmonaut died on reentry. If Soyuz 2 had launched, the crew wouldn’t have survived.

Vladimir Komarov, the cosmonaut who died in the ill-fated Soyuz 1

Vladimir Komarov, the cosmonaut who died in the ill-fated Soyuz 1

This was 1967, a year before Apollo 7. The Soviets went for broke, testing rockets, capsules, rendezvous, and more in one mission. On paper, it looked like they were ahead. The result was failure — and an 18-month delay in the program, and ultimately failure to get to the moon before the Americans. Indeed, Soyuz 4 and 5 in early 1969 eventually completed the mission aims of Soyuz 1 and 2.

The tortoise beat the hare. It was a pretty fast tortoise, but you see the point. The pragmatic approach of trying one complex new component in each mission ultimately made the Apollo program successful. Doing everything at once didn’t work. There’s something in that for all of us. See you next time.

Writing a Book

One day I’ll write another book. Perhaps a sports book about people and their stories, or the story of search engines and the people that build them.

I wrote my first book in 2001 with David Lane, and we rewrote it in 2003 for the second edition. I wrote another book with Saied Tahaghoghi in 2004 – the truth is I started it, and he picked up the pieces when I changed careers and countries; he’s a good man. The first book sold over 100,000 copies over the two editions (I still get a royalty check quarterly) and the second modestly (Saied and I earned our advance back). They’re both dated, old books now.

Web Database Applications with PHP and MySQL. My first book in its second English edition.

Web Database Applications with PHP and MySQL. My first book in its second English edition.

It’s thousands of hours of work to write a book. I spent at least 20 hours per week for 18 months on the first edition of the first book – that’s 1500 hours at least. I got out of bed at 5:30am and I did a few hours of writing before work. I’d also squeeze in a little more after work (typically some proof reading), and a longer period of writing on the weekend (where I’d still get out of bed at 5:30am).

Did I get rich? No. Typically, the authors get less than 10% of the wholesale book price — a couple of dollars per book sold at most. I got more than the minimum wage for the first book (roughly dividing the royalties by the number of hours by the number of authors to get an answer). The second book didn’t pay its way.

The longer I worked in a single sitting, the more productive I was. It takes a certain fixed amount of startup time to begin writing – you reread what you’ve written, edit it a little, get the context back, think about the structure of what you want to say next, and then start writing anew. But I can’t write for an extended period – it’s tiring, and I need to stop and take time away to think about what I want to do next. Three or four hour stints are the most productive for me.

When I wrote the first book, I’d count how many words I wrote in a session, and use that as a measure of success. I’d decide that I was going to write 1000 words before I took a break. It turns out, that doesn’t work for me: I’ve learnt that what’s important is sustained output, averaged over a month or so. Some days, I’ve got writer’s block. But I’ve learnt that that’s when I am doing valuable thinking – I’m working through a larger problem, or thinking through structure, or solving something that’s been bugging me for a while; sometimes, this is a subconscious activity. Other days, I’m a machine: I write as fast as I can type, and thousands of words flow. A whole chapter has been known to flow after a writer’s block.

My second book, Learning MySQL in its one-and-only edition.

My second book, Learning MySQL in its one-and-only edition.

Writing slows down as the book takes shape. I’ll be in the middle of a new section, and I’ll want to reference something else I wrote using something like “as you learned in Chapter <x>, the <something>”. Then I have to figure out what chapter it was, and what exactly was that <something> – that takes time. And, as the book gets longer, you repeat yourself – at least, my memory isn’t amazing enough to make sure I only say the same thing once. I’ll find myself waxing lyrical about some great idea, only to discover that it is somewhere else in the book too. Then it’s a case of figuring out where it should be – which is going to lead to editing a was-finished chapter elsewhere in the book or rethinking what I’m writing today.

I worked with a major publisher, O’Reilly Media Inc., and the wonderful editorial skills of Andy Oram helped me on both books. Editors are awesome – they push, prod, ask questions, push for clarity, and say things that make your book better. But they create a ton of work – you’ll get feedback such as “Perhaps you could merge those two chapters?” or “Chapter 4 needs to be broken into two chapters, and you need to really go into much more depth”. That often happens after you think you’re finished. You’ll get asked for extra chapters, rewrites, more or less content, and complete changes in style. It makes your book better. Between the first edition and second edition of my first book, Andy helped me change my style from a formal computer science style to a more conversational, chatty style – the kind that I use in this blog.

Writing a book isn’t a social experience. You need to enjoy being alone with your thoughts. Prepare for one hour of inspiration and conversation to turn into a hundred hours of hard labor and iteration. If it takes a couple of thousand hours to write a book, ten of them are the inspirational ones where you create the fundamental ideas. I wrote much of the second book in my parent’s Winnebago – parked on the grass, a good distance from the house, deliberately without wifi, and with nothing inside to distract me.

So, why do it? I enjoy writing – there’s rewarding impact in sharing knowledge with thousands of people. If you’re lucky, someone’s success or their impact will be because of what you shared. Or maybe you change how someone thinks or sees the world. Or you make their life better. It’s also cool to see your name on the cover, and to feel it in your hands – it’s even cooler when it’s translated into a language you don’t understand. I wonder what joy there is in knowing people are reading a digital copy? The digital sales on the royalty statement have never quite inspired me the same way.

Have fun. See you soon.

Changing platforms at Scale: Lessons from eBay

At eBay, we’ve been on a journey to modernize our platforms, and rebuild old, crufty systems as modern, flexible ones.

In 2011, Sri Shivananda, Mark Carges, and I decided to modernize our front-end development stack. We were building our web applications in v4, an entirely home-grown framework. It wasn’t intuitive to new engineers who joined eBay, they were familiar with industry standards we didn’t use, and we’d also built very tightly coupled balls of spaghetti code over many years. (That’s not a criticism of our engineers – every system gets crufty and unwieldy eventually; software has an effective timespan and then it needs to be replaced.)

Sri Shivananda, eBay Marketplaces' VP of Platform and Intrastructure

Sri Shivananda, eBay Marketplaces’ VP of Platform and Intrastructure

We set design goals for our new Raptor framework, including that we wanted to do a better job separating presentation from business logic. We also wanted better tools for engineers, faster code build times, better monitoring and alerting when problems occur, the ability to test changes without restarting our web servers, and a framework that was intuitive to engineers who joined from other companies. It was an ambitious project, and one that Sri’s lead as a successful revolution in the Marketplaces business. We now build software much faster than ever before, and we’ve rewritten major parts of the front-end systems. (And we’ve open sourced part of the framework.)

That’s the context, but what this post is really about is how you execute a change in platforms in a large company with complex software systems.

The “Steel Thread” Model

Mark Carges, eBay's Chief Technical Officer

Mark Carges, eBay’s Chief Technical Officer

Our CTO, Mark Carges, advocates building a “steel thread” use case when we rethink platforms. What he means is that when you build a new platform, build it at the same time as a single use case on top of the platform. That is, build a system with the platform, like a steel thread running end-to-end through everything we do.

A good platform team thinks broadly about all systems that’ll be built on the platform, and designs for the present and the future. The risk is they’ll build the whole thing – including features that no one ultimately needs for use cases that are three years away. Things change fast in this world. Large platform projects can go down very deep holes, and sometimes never come out.

The wisdom of the “steel thread” model is that the platform team still does the thinking, but it’s pushed by an application team to only fully design and build that parts that are immediately needed. The tension forces prioritization, tradeoffs, and a pragmatism in the platform team. Once you’re done with the first use case, you can move onto subsequent ones and build more of the platform.

Rebuilding the Search Results Page

Our first steel thread use case on Raptor was the eBay Marketplaces Search Results Page (the SRP). We picked this use case because it was hard: it’s our second-most trafficked page, and one of our most complex; building the SRP on Raptor would exercise the new platform extensively.

We co-located our new Raptor platform team – which was a small team by design – together with one of our most mission critical teams, the search frontend team. We declared that their success was mutually dependent: we’re not celebrating until the SRP is built on Raptor.

We asked the team to rebuild the SRP together. We asked for an aggressive timeline. We set bold goals. But there was one twist: build the same functionality and look-and-feel as the existing SRP. That is, we asked the team to only change one variable: change the platform. We asked them not to change an important second variable: the functionality of the site.

This turned out to be important. The end result – after much hard work – was a shiny new SRP code base:  modular, cleaner, simpler, and built on a modern platform.  But it looked and behaved the same as the old one. This allowed us to test one thing: is it equivalent for our customers to the old one?

Testing the new Search Results Page

We ran a few weeks of A/B tests, where we showed different customer populations the old and new search results page. Remember, they’re pretty much the same SRPs from the customers’ perspective. What we were looking for were subtle problems: was the new experience slower for some scenarios than the old one? Did it break in certain browsers on some platforms? Was it as reliable? Could we operate it as effectively? We could compare the populations and spot the differences reasonably easily.

This was a substantial change in our platforms and systems, and the answer wasn’t always perfect. We took the new SRP out of service a few times, fixed bugs, and put it back in. Ultimately, we deemed it a fine replacement in North America, and turned it on for all our customers in North America. The next few months saw us repeat the process across our other major markets (where there are subtle differences between our SRPs).

What’s important is that we didn’t change the look and feel or functionality at first: if we’d done that, we may not have seen several of the small problems we did see as fast as we saw them.

Keeping the old application

Another wise choice was we didn’t follow that old adage of “out with the old, and in with the new”. We kept the old SRP around running in our data centers for a few months, even though it wasn’t in service.

This gave us a fallback plan: when you make major changes, it’s never going to be entirely plain sailing. We knew that the new SRP would have problems, and that we’d want to take it out of service. When we did, we could put the old one back in service while we fixed the problem.

Eventually, we reached the confidence with our new SRP that we didn’t need the old one. And so it was retired, and the hardware put to other uses. That was over a year ago – it has been smooth sailing since.

The curse of dual-development

You might ask why we set bold goals and pushed the teams hard to build the new Raptor platform and the SRP. We like to do that at eBay, but there’s also a pragmatic reason: while there’s two SRP code bases, there’s twice the engineering going on.

Imagine that we’ve got a new idea for an improvement to the SRP. While we’re building the new SRP, the team has to add that idea to the new code base.  The team also has to get the idea into the old code base too – both so we can get it out to our customers, and so that we can carry out that careful testing I described earlier.

To prevent dual development slowing down our project, we declared a moratorium on features in the SRP for a couple of months. This was tough on the broader team – lots of folks want features from the search team, and we delayed all requests. The benefit was we could move much faster in building the new SRP, and getting it out to customers. Of course, a moratorium can’t go on for too long.

And then we changed the page

After we were done with the rollout, the SRP application team could move with speed on modernizing the functionality and look-and-feel of the search results page.

Ultimately, this became an important part of eBay 2.0, a  refresh of the site that we launched in 2012. And they’re now set up to move faster whenever they need to: we are testing more new ideas that improve the customer experience than we’ve been able to before, and that’s key to the continued technology-driven revolution at eBay.

See you next week.

The size, scale, and numbers of eBay.com

I work in the Marketplaces business at eBay. That’s the part of the company that builds ebay.com, ebay.co.uk, ebay.de, ebay.com.au, and most of the other worldwide marketplaces under the eBay brand. (The other major parts of eBay Inc are PayPal, GSI Commerce, x.commerce, and StubHub.)

I am lucky to have opportunities to speak publicly about eBay, and about the technology we’re building. It’s an exciting time to give a talk – we are in the middle of rewriting our search engine, we’ve improved search substantially, we’re automating our data centers, we’re retooling our user experience development stack, and much more.

At the beginning of most talks, I get the chance to share a few facts about our scale and size. I thought I’d share some with you:

  • We have over 10 petabytes of data stored in our Hadoop and Teradata clusters. Hadoop is primarily used by engineers who use data to build products, and Teradata is primarily used by our finance team to understand our business
  • We have over 300 million items for sale, and over a billion accessible at any time (including, for example, items that are no longer for sale but that are used by customers for price research)
  • We process around 250 million user queries per day (which become many billions of queries behind the scenes – query rewriting implies many calls to search to provide results for a single user query, and many other parts of our system use search for various reasons)
  • We serve over 2 billion pages to customers every day
  • We have over 100 million active users
  • We sold over US$68 billion in merchandize in 2011
  • We make over 75 billion database calls each day (our database tables are denormalized because doing relational joins at our scale is often too slow – and so we precompute and store the results, leading to many more queries that take much less time each)

They’re some pretty large numbers, ones that make our engineering challenges exciting and rewarding to solve.

Any surprises for you?