Techies love hackathons. What could be better than getting together for an evening, or a weekend, with food, friends, maybe a beer, and using one’s magic powers to create a piece of technology that saves the world?
I exaggerate. Most people don’t think they’ll save the world in a weekend, but sometimes they act as if they believe they can.
As software professionals, when was the last time we went to our bosses and said “No problem. I’ll build that brand new production system for you in 8-16hrs”? Probably never.
Certainly not as often as we’ve freaked-out when the boss came to us with some impossible deadline. “You can’t expect me to build something effective, reliable, great in N-months!” we scream. “Be reasonable!”
So why do we sell the myth of the 2-day app to non-profits and other mission driven organizations?
Maybe we like the buzz of seeing ourselves as heroes able to jump tall-buildings with our nerd super-powers.
Or maybe we just like the pizza.
Either way, there are several problems with the way a typical hackathon model that make it almost impossible for them to succeed. I list some specifics below, but first I can sum up the core issue:
Hackathons just aren’t serious. They are in no way up to the challenge of delivering effective, useful, impactful technology.
A little more detail:
- Understanding the problem. Tough problems are complicated and require complex solutions. When we attend a hackathon, we expect to show up, read a paragraph long problem definition, decide on a solution, and start typing without any research or study.
- Our customers can’t commit to the effort until we do. Hackathons don’t guarantee delivery of useful functioning software. Volunteers who attend don’t commit to finishing a project, just to spending a weekend and maybe some non-committal “follow-up volunteer time.”If we can’t promise results, how can the people we are trying to help commit the time and effort required to shape and adopt some new technology? Most can’t and don’t. So even when we do deliver something, it often arrives at an organization with little (if any) organizational commitment or ability to use it.
- Hackathons can be a burden on our customers. The organizations we want to help are tackling hard problems with very few people and very little money. Helping us prep problems, participating in the hackathon, and trying to politely guide well-meaning (but rarely committed) post-hackathon volunteers takes time.When I was CTO of a non-profit, it seemed so rude to turn down an offer of help. A few times I spent time out of my crazy-busy day to work with nice people who wanted to volunteer (including throwing hackathons). In retrospect, I shouldn’t have—we never received any deliverable that we couldn’t have hacked quicker ourselves.
- Software Technology Takes Time to Build. We’re aren’t painting a community-center rec-room. Software takes time! And half-finished software is useless. What about the occasional project that really only take a couple days of effort? My colleagues at ThoughtWorks like to point to this good piece of pro-bono effort we performed. But even in this case, it wasn’t just a few days of coding. Our efforts included an ongoing commitment to keep the live service operating as long as it was needed.
- Building it right takes sustained, ongoing, engagement. This one should be self explanatory to software professionals, yes?
Most programmers are familiar with Brooks’ Law that 9 women can’t have a baby in one month. When we pretend we can accomplish something in a hackathon or two we it’s like 50 people making baby in 2 days, and then we let it starve.
So should we just give up and enjoy the pizza and socializing without pretending we are saving the world?
No. We can get serious and we can learn from people who have models for successful volunteering.
While writing this blog I decided to call a friend who I thought could help me think through a better approach. He’s a software entrepreneur. He’s also a carpenter and a long time volunteer with Habitat for Humanity.
Habitat accomplishes something pretty amazing. They regularly plan and complete complex, long-duration projects using a mixture of sweat-equity from soon-to-be homeowners, paid experts, and volunteer efforts from both amateurs and skilled professionals.
For those of you who don’t know Habitiat, they build houses—everything from simple single-family homes, to multi-unit urban condo developments.
It would be too long a blog post to go into all the details of how they accomplish this, but here are some key elements that could be used in a successful volunteer software development project.
- Take the task as seriously as you would your own work. You wouldn’t want to live in a house a bunch of yahoos hammered together in a weekend. You wouldn’t want your business or your favorite non-profit running on software a bunch of yahoos hammered together in a few hackathons.
- Commit to delivery. Habitat doesn’t say “we’ll hold a hammerathon once-a-month and see what we get.” They commit to building a finished house.
- Get commitment upfront and engage customers throughout. Habitat home-owners are screened and selected ahead of their building project. They commit, from the beginning, to work for a year or more to build their house. They have skin-in-the-game, and they are going to use that home.
- Continuity and follow-through is a job. Habitat acts as developer, financier, and general contractor on their projects. They have full time (paid) managers on staff that plan projects, recruit volunteers, and see the work through to completion.The minimal equivalent on a software project is a product owner and a project manager to see the work through from conception to delivery.
- Some things you pay for. Habitat is very good at getting trained professionals to donate their services—like architects who contribute plans pro-bono. But sometimes you just need to pay someone. Often these are skilled tradespeople like plumbers and electricians. If we can’t find volunteers with the right skill on a volunteer software project, we need to find a way to pay someone. Perhaps a UI designer or two.
- Volunteer events add energy and attract contributors, but they are a small part of a larger sustained project plan. Habitat works hard to bring volunteers to project sites on a regular basis. Those volunteers have fun and perform valuable work. But these weekend-events are not the only (or even main) source of effort. The events fit into an overall project plan. The short term volunteers, when they show up at a work site, are directed by full time workers both paid and long-term volunteers.THIS is where hackathons can fit in. They can inject energy to a project and attract long-term volunteers. They can be critical components of a larger framework.
If we want to provide real value for the organizations we are looking to help, we need to expand our efforts beyond these fun little events and find ways to create (and pay for) an ongoing sustained project effort.
What if you (or your company, or your hacker-group) can’t can’t commit to an ongoing project?
The Habitat analogy still holds. You don’t have to be Habitat for Humanity to do useful work. You can be a one-weekend volunteer. The key to being a useful one-weekend volunteer is to make sure someone else is seeing the project through and that you are helping them.
So if you can’t commit to following through on a many-month, many year project—and let’s be honest, most of us can’t—you can make sure that your efforts are serving the people who have committed for the long run.
- Ask more from your hackathon sponsors. If you want a company to help out, don’t just ask for a conference room for a weekend. See if they will commit a product owner/project manager to see the project through to the end.This could be by taking one key bit of work that comes out of the hackathon and committing to organizing volunteers for many months to complete it.
- Is that asking too much? There is an easier way. Have your hackathon contribute to a long running humanitarian software project that already has a committed core set of developers and managers. Projects like OpenMRS.If you do this, remember that engaging these organizations does sap some of their effort. So make sure your hackathoners are committed to at least returning enough value to cover the time OpenMRS or OSM will spend helping you organize.
At the end of the day, it’s about caring more about the value we provide, the outcomes more than the pizza and beer and ego-stroking we know we’ll receive.
ThoughtWorks’ is getting serious about explaining and promoting its Social Impact Program. Here is v1 of the recently completed Social Impact Program overview brochure. It comes formatted for US (Letter) and EU/UK(A4) paper in case you want to print one out.
I prefer the PDFs myself!
We live in a time of global revolution—a revolution enabled by technology and, as with all revolutions, driven by people. It’s not a socio-political revolution like the Arab Spring or the Occupy/99% movement—though those movements have been substantially enabled by technology.
This revolution is more mundane, yet deeply transformational. It is driven by two key technologies: Mobile Networks and Cloud-Hosted Services.
These two technologies give organizations—governments, giant international Non-Governmental Organizations (NGOs), social enterprise entrepreneurs, community organizations, and even individuals—the ability to:
- Communicate readily with field staff, volunteers, and the beneficiaries of their services, however remote.
- Scale their services to national and global levels.
This technology-enabled ability to “talk to everyone, everywhere, without a ton of technical expertise, and for not a lot of cash” is literally changing everything for people who live and work where there is little of the big infrastructure (power, wire-line phones, wired-Internet, highways,plumbing) of the “developed” world.
Paper and the Bad Old Days (they’re still here)
Much of the world runs on paper. Paper doesn’t need power. It doesn’t need software security upgrades. It’s available everywhere. But it’s a terrible way to collect and analyze the data you need to run your organization.
In 2008, as CTO of Inveneo, I worked on a project with the World Health Organization (WHO) and the Sierra Leone Ministry of Health and Sanitation (MoHS)—here’s a blog post about the project’s kick-off trip. The project was simple: replace the paper forms used in hospitals with an open source health statistics package. Not only was statistics gathering via paper slow, expensive, and frustrating, it was wildly inaccurate—an analysis of ministry data showed far more babies received their 3rd vaccination shot than received their 2nd shot. Think about it. How can a baby get the 3rd of something without getting the 2nd? Vaccination data, at least, was bogus.
Paper plus Landcruisers to carry the paper to headquarters is state-of-the-art in many parts of the world. And I’ll be honest—our project in Sierra Leone did not fully solve the problem. We replaced paper with data files, but a staffer from the ministry still had to ride a motorcycle around the entire country collecting files on a USB stick to bring them to HQ!
Last year, I travelled to Madagascar to work with Human Network International, an NGO that provides communications services to other NGOs. One of HNI’s clients manages a network of over 200 private medical clinics to provide sexual and reproductive health services. They told us that they had never—ever—successfully collected a complete monthly report on the services they had provided. Think about that a moment. Imagine running a business, running it foryears, and never once knowing accurately and completely, what you had done in any given month.
The good news is that with HNI’s help and the amazing ubiquitous infrastructure provided by Madagascar’s mobile phone companies (MNOs in industry-speak), this has changed. Monthly reports are rolling in, complete and accurate.
Now this organization is having crazy thoughts—like communicating directly with their patients to provide them critical health information and to hear directly from them about the care they are receiving. It sounds so simple, but it’s revolutionary: entire populations of people who have been lucky to receive any health services at all will be able to demand the quality of service they deserve.
Half a Revolution: Ubiquitous Mobile Networks
Remember the medieval concept of “aether,” an invisible element that fills every corner, every crack of the entire universe? It’s real. We’ve built it here on earth. It’s called the “mobile phone network,” and it covers the entire planet, almost. According to an International Telecommunications Union report from 2008, in 2005 82% of the earth’s population lived in range of a mobile network signal. The same report predicted that by 2011 90% of the world would live in the aether of a mobile network. Here is the section of the ITU’s ICT Regulation Toolkit that quotes the research.
I spent some time searching for newer figures, and Google failed me. But I suspect we’ve achieved far greater coverage than the report from 2008 predicted. Smarter, better-informed, better-looking people than I have told me that today somewhere between 95% to 98% of all humanity live in range of a signal. The vast majority of these networks carry data as well as voice. Some are slow (GPRS), some are fast (3G/4G), and all offer SMS. So in some form, data transmission (“the Internet”) is also ubiquitous.
Not everyone has a phone. The ITU report says that in 2006, “only” 50% of the world’s population had a mobile phone—which is still stunning—but that data is 5 years old. More recent data shows an accelerating trend to universal phone ownership. PhoneCount mashes up various data sources and estimates we are 90 days (as of this writing) from “everyone connected” day.
PhoneCount is overly optimistic. We are some distance from universal ownership. Often, “access” means one phone in a family, controlled by a man. There are stubborn pockets of unconnectedness, but, even noting these caveats, this is a revolution: for the first time in human history, (nearly) everyone can communicate, in real time, with voice, or data, to (nearly) everyone else.
The Other Half: Living in a Cloud
Phones are great. But phones alone are half the story. The other half is hidden away in dark, cool, warehouses in Oregon, Ireland, and Singapore. Stuffed with servers, these warehouses are what the marketers call the “Cloud.”
Why should anyone care? Two reasons:
- Scale. Servers mean scale. 200 hundred doctors voice-calling headquarters with monthly updates may be a pain, but manageable; 1000 doctors is not. How does Facebook handle 800 million customers with only about 3000 employees? Servers!
- It’s someone else’s problem. Most mission-driven organizations have very few information technology experts. Many of them have none. So unlike Facebook (with their thousands of tech geeks) they can’t build or run their own technology.
I think this is good. A Malagasy reproductive health NGO should spend its time being expert onreproductive health in Madagascar, not learning Linux, Ruby, PHP, Java or any of the rest of that technical mumbo-jumbo. Unsexy Cloud server farms are run by technology companies that handle some very complicated (and to be honest, pretty sexy) technical problems so that you and I can access the power of the Cloud without being particularly technical ourselves.
I’m not suggesting that mission-driven organizations aren’t capable of being technology experts; I just don’t think they should have to.
The Reach of the Cloud
But wait, you say, is the Cloud available in the developing world? No, not everywhere. But it is everywhere the Internet is, and it’s growing quickly.
As recently as 2009, there was no direct Internet backbone connectivity to East Africa—all traffic went through expensive, slow, satellite links. Since 2009, new undersea cables and land-based fiber-optics networks have brought massive capacity to East Africa. Kenya’s wildly successful mobile money service M-Pesa lives in the Cloud, running on servers hosted in Europe by Rackspace.
With Cloud-hosted services, technically expert companies (and non-profits) can offer scaled services (not technology) to mission-driven organizations. This is the key: they offerservices not gadgets. Gadgets have to be learned, operated, and maintained. The care and feeding of technology is expensive and difficult. Services are someone else’s problem!
Mobile+Cloud = Service Explosion
The combination of Mobile and the Cloud as a platform for scaled services (run by someone else) is a launchpad for massive innovation: (nearly) any organization can offer scaled services to (nearly) anyone.
ThoughtWorks’ Social Impact Program is very proud to have contributed to the development of several Mobile/Cloud services for mission-driven organizations. Below are brief descriptions of a few of these projects.
- Simpa Networks—How does a company make solar power available and affordable to people in rural India when the upfront cost of solar equipment is 3 to 5 times a family’s annual energy budget (typically spent on kerosene and candles)? Low-upfront-cost pay-as-you go power backed by a Cloud/Mobile payments system! Watch Simpa founder Michael MacHarg describe their work.
- CycleTel™—Georgetown’s Institute of Reproductive Health wants to bring their fertility-awareness family planning method to India. How do they scale this method, currently available to North American women in the form of physical beads to millions of Indians? Mobile (SMS) backed by Cloud-hosted servers.Read a case study about the CycleTel™ project
- RapidFTR—Initiated by New York University’s Interactive Telecommunications Programand UNICEF Innovation, RapidFTR is an open source project that “Helps aid workers collect, sort and share photographs and information about children in emergency situations so they can be registered for care services and reunited with their families.” RapidFTR combines Smartphone clients with a server infrastructure that can be deployed in the Cloud so that people managing an emergency don’t have to wrestle with technology when they have more pressing problems. It can also be run locally if connectivity is unavailable.
- DataWinners/Mangrove—collaboration with Madagascar-based Human Network International (HNI) and Columbia University’s Modi Research Lab, Mangrove is an open source framework for building mobile-data collection systems. DataWinners, built on Mangrove and operated by HNI in a Cloud-hosted service, provides mission-driven organizations with mobile-data collection capabilities through a zero-technical-skills-required self-serve web application.
When Steve Jobs resigned from Apple a few weeks ago it was clear he was very sick, probably dying. It had to be that serious to tear him away from his company. Even so it came as a shock yesterday when I received this slightly cryptic text: “Condolences to you for your insanely great ex-boss.”
“Insanely Great” is a Steve Jobs catch-phrase. I knew what the message meant. A quick look at the New York Times home page confirmed.
Steve was never really my ‘boss’, but I did work for his company NeXT Computer, and he was an influence in my life long before I had the chance to meet him.
My mother introduced me to computers when I was in the 4th or 5th grade. At a time when home computers were rare she had an ‘acoustic coupled portable teleprinter’, a lot like this one, from her MBA program. She taught me BASIC and gave me a copy of Soul of a New Machine,.
I was hooked. From then on all I wanted to do was work at a computer start-up—not a dry east coast mini-computer company, I wanted to work at Apple, for Steve.
A few years later I applied to Stanford University, mostly because it’s in Silicon Valley—where Apple is.
At Stanford, I worked in the computer center selling and repairing Macintosh’s. It’s there that I saw a demonstration of the NeXT Cube. It was beta, not yet for sale, and it was going to cost $6,500. The only way I could think to get one was to work for NeXT—which I’d decided to do anyway once I learned that Steve had left Apple and started NeXT.
Near the end of my freshman year, desperate for a summer job, and jonesing for a Cube, I sent an email to the saleswoman who’d given the demo.
To my roommates’ surprise (and to be honest, mine as well), she called me (thank you Cindy!) and introduced me to a co-worker who, by chance, was pitching the idea of a NeXT campus rep program. What followed was a endless stream of interviews (I wasn’t just being interviewed, I was being paraded as the poster-boy for the potential program), and before heading home for the summer, NeXT hired me (thank you Sandy!)—as an hourly contractor for not much more than minimum wage—and promised me a Cube.
They also invited me to the 1.0 launch party for the computer. A few weeks after my 19th birthday I found myself at NeXT headquarters, champagne in hand, being introduce to Steve Jobs.
It didn’t go well. I was nervous. I don’t remember clearly, but I’m pretty sure I spilled my drink on Steve and he yelled at me.
Fortunately the job went better. In less than a year, I passed the campus rep job to a friend and started working at NeXT directly, for the marketing department. Work was interesting, and busy, and I decided to drop out of college to work full time. After about a year as the college drop-out on the ‘Higher Education Marketing Team’, I dropped out of NeXT to return to school.
I didn’t have much interaction with Steve during my time at NeXT. He was the founder, the CEO, the owner, the legend. I was literally the lowest person on the totem pole—a college kid earning around $10/hr. But I did get to work with the amazing people he hired around him. NeXT was not a success, but it was an amazing place to be.
My most personal interaction with Steve happened a couple years later. I had graduated and taken a job as an engineer at an Apple spin-off that was developing a new operating system—a potential NeXT competitor. I hadn’t returned to NeXT because they saw me as a ‘marketing guy’ and I wanted an engineering job. The company I joined was a disaster, but I was a star there. I was leading engineering teams, writing good code, and generally feeling good about myself.
One day my desk phone rings: “Hi”, says a familiar voice, “this is Steve Jobs. I hear you are the smartest guy over there and that I was stupid to let you leave NeXT. I want you to come back and interview for an engineering position.” So I did.
Thing is, I was a 23yr old with a big head. NeXT made it clear that they wanted me, but they wanted me as a junior engineer (I was just 1yr out of college) not a team lead or a manager.
The folks at NeXT were of course right, I was a big fish in a not-very-competent pond, and they were offering me a small fish job, but with a rock-star team. Even so the offer felt like a step backward and I turned it down.
A week or so later, my home phone rings. “Hi, this is Steve Jobs, I hear you turned us down. Want to tell me why?” I was shocked. Steve had a few more important things to do than chase down a potential junior engineer, but he didn’t like to lose, and he was famous for finding a way to micro-manage.
I was too intimidated to tell the truth, so I mumbled something about needing to finish off projects not leaving people in the lurch.
“It’s your decision, but I’ll tell you something: you’re 23. If you are the smartest person at your company, you’re at the wrong place.”
Steve’s known for that kind of insightful zinger. With one short sentence he popped my inflated ego and reminded me who I was: a 23yr old punk, smart, but with a lot to learn. I still didn’t want a junior job at NeXT, but I knew I couldn’t stay where I was. I lasted a couple of weeks and then quit.
That’s pretty much the extent of my direct relationship with Steve—a spilled drink, a few years as the most junior person at his failed company, a couple of phone calls.
His biggest impact on me wasn’t anything personal: it’s the same impact he’s had on everyone: his creations, what he symbolizes and how he changed the way we think.
Growing up on the east coast I was—even as a kid—keenly aware of the importance of status—family name, parents money, prep-school attended, ivy league university attended—and I hated it. To me Steve represented a kind of utopian world—a meritocracy where talent and ideas matter more than status. A place where a great idea means everything, and where a jeans-wearing college drop-out adoptive-child of working class parents becomes Silicon Valley’s greatest hero.
I know that Silicon Valley and the tech industry are not utopias—status and money matter, but at the same time the meritocracy is real. Ideas, and the people who make them real, can succeed wildly no matter their background. Steve is the example that makes this real.
The most amazing thing Steve did was teach the world the value of design and the importance of not just doing something well, but making it simple and beautiful and amazingly unbelievable mind-blowingly, and yes, insanely, great.
It seems crazy now, but there was a time when people (and companies) had to be argued into spending time and money on design.
Even the companies that ‘got it’ saw the scope of design as very limited. Sony ruled consumer electronics with beautiful industrial design–they made gorgeous physical things. But they never understood the importance of extending that aesthetic and usability to the non-physical components of their products.
This is how Steve kicked Sony’s butt with the iPod.
But of course Steve’s design sense doesn’t stop with hardware or software. It extends to the entire experience of discovering, buying, learning, using. Apple products have gorgeous industrial design that integrates beautifully with some of the best UI on the planet. But Apple also integrates services (e.g. iTunes) and have packaging so good that an internal Microsoft design group made this parody of their own work hoping (unrealistically it seems) that they could be allowed to create Apple-like design.
And Apple can’t stop with the product—the experience extends all the way to Apple’s stores, educational programs, ‘genius’ bars, to how you find and fall in love with their products; how you learn to use them; and even how you get them fixed.
The reason Apple-fans can feel like a cult is because Steve has expanded the scope of design so far that to own an Apple product is to be part of an encompassing experience and community that has no start or end. Maybe it is a cult.
I’m sad today. Sad of course for Steve and his family and friends. I’m also sad because this is the close of a chapter in my life. Steve was a symbol of a dream that I’d had since I was 10. He was an almost embarrassingly concrete inspiration—I became obsessed with computers because of him. I moved to California because of him. I found work at NeXT because of him. I founded my own start-ups because he showed us that ideas, and fighting to make them real, change the world. And, of course, because I wanted to be like him.
It’s been a hectic week here at SoukTel. The first couple of days were full on with Andy and me leading the SoukTel team through a number of sessions.
Apart from the discovery sessions into the SoukTel world, some of the sessions we covered were:
- Agile Software development Lifecycle
- Retrospectives and why are they helpful
- What is a story and where is the value
- Distributed Development
- Release planning
The SoukTel team works in a very dynamic environment and we realised that the full process we use on projects may not be valuable for them. Therefore, most of these sessions were overviews to give the SoukTel team an understanding of what is involved in each aspect of our typical process. Afterwords, we will hand pick parts of our process that are relevant to their organisation.
The rest of the week was filled with us splitting up and beginning to understand the day to day tasks of the two teams (Business and IT). One of our major challenges is to try not to be too disruptive of the
individuals, as this might compromise their project deadlines. Another challenge is the distributed layout of the office. The SoukTel team is physically segregated into business and IT and we need to get visibility into both. How do we bring the two groups together and show them the benefits of being in the same space?
The dynamic nature of their requirements breeds an environment where the team is very reactive in nature. To try to mitigate this, we will be looking into facilitating sessions where the team can decide on a standard project life-cycle process. Our fundamental advice is that with some additional structure comes communication, visibility and risk mitigation. Their ongoing homework is to try this process for a while and evolve it as they go along.