Archive for the ‘Teaching ICT4D’ Category

Random Hacks of Partial Kindness

May 14, 2011

Tate Watkins at the Mercatus Center at George Mason University prompted the Jester with the following question for a post to AidWatch: “Is it reasonable to expect that Random Hacks of Kindness (RHoK) and similar events will produce ‘solutions to development problems’?”

The Jester’s simple answer to that direct question, of course, is “no.” Anyone imagining that a day or two of hacking will produce solutions to development problems, even in some small part, is either a technologist drunk on her own self-image who believes that she’ll solve a mindboggling social challenge with technology, or a World Bank officer drunk on his own self-image who believes that he’ll solve a mindboggling social challenge by motivating some technologists. In any case, it seems clear they are the kind of folks who don’t learn from history.

Surprisingly, the Jester has a more complex answer to the underlying question, which might have been posed as, “Do events such as RHoK do any good?” The answer to that question is far more complicated, because these events have multiple goals, and some of the goals are not half bad, even if they could still use some course correction.

The first and most obvious surface goal of events like RHoK is to end up with a body of software that could somehow impact international development. The Jester has written extensively about this notion (for example, through his puppet, at the Boston Review), and the short answer is that exactly where we most want such technology to have impact, the required human intent and capacity to make the technology itself work is low. Combine this with the fact that very little successful software in the world gets written via a two-day hackfest, and the likely interesting impact will be zero.

The second goal of RHoK is likely to support the building of software programming capacity in developing countries. Of their currently posted 20 or so physical hosting sites, 6 or 7 are in developing countries (and of those, about half by groups well-known to the Jester), and to the extent that these events generate excitement around the ability to develop software in developing countries, they are fantastic, as the Jester implied in a previous post. Among the things that makes a country “developed” is its intrinsic capacity to create, adapt, and master technology, and to the extent that the efforts highlight the aspiration of those within country to do so, the Jester applauds. (However, as long as developer development is the goal, why not have the contest be around software that would really be useful?)

A third and less obvious goal of RHoK is to encourage software developers in the developed world to engage on problems in the developing world. The Jester has mixed feelings about this, because on the one hand, it’s great to encourage people anywhere to care about others who are in less privileged circumstances; on the other hand, further contributing to the vain belief that that intention can manifest through random hacks of software development is dubious. Good software developers would have more value by mentoring less experienced software developers in the developing world, than attempting to solve a developing-world problem through technology. The latter is still just another kind of charity, and another kind of “giving people a fish.”

A fourth goal might be build to a community around software developers in the world who care about international development. The Jester strongly believes in the value of community, and often times, the development of community — even if it for a misguided instrumental end — can be redirected later to more useful purpose. Strong communities have value, especially to the extent that their mission is really to solve development challenges. However, as with the other goals, the end impact of the community will depend on what it decides to do with its social capital.  

So, to different RHoK stakeholders, the Jester has different things to say:

  1. For budding software developers: Use the event to learn more about software development. And, for those coming from a developing country, involve more friends. The ability to write good code is exactly the kind of capacity that will help individuals earn good incomes and help countries grow economically.
  2. For experienced software developers hoping to “do good”: The intention is laudable. The most meaningful impact, though, will come not from technological artifacts, as much as from the mentoring of people in the first category.
  3. For sponsors: If the goal is practical software, the phrase “barking up the wrong tree” appears next to the Jester’s head as a thought bubble. If the goal is to help developing countries gain software-developing capacity, shift focus to the end-to-end supply chain of human capital for engineering, i.e., education defined very broadly. In the current global economy, there is no shortage of demand for capable software engineers. But, supply is hurting. And, if the goal is to kill multiple birds with one stone, try hitting one bird first; no point aiming for their empty center of gravity! (The Jester does not wish to promote violence against animals, but the available proverbs along these lines are limited.)

And, to wrap up with a single sentence: The most meaningful way for the RHoK to have impact is for everyone to focus on increasing the software-developing capacity of the least experienced developers (wherever they’re from) who come to hack.

Bad Influence

April 28, 2011

The Jester recently attended yet another conference on doing good with ICT. He initially wondered whether he should attend, but went for three reasons: (1) the event happened only blocks from the royal palace; (2) several of his old pals were there (from the days before the Jester was rescued from his depravity by the royal court); and (3) in spite of himself, the Jester hoped there might be some enlightenment among save-the-world technologists.

Alas, there was little sign of nirvana. Although there were a handful of presentations by those who had attained moksha, their wisdom was lost among the many fancy plans to scale positive change with ICT (which the Jester doubts ever happens even in alternate universes).

One thing the Jester did notice, however, was the incredible bluster of some of the presentations. In fact, the less evidence there was that good work was happening, the more confidently the speakers seemed to project the future potential of their technology projects.

The only other context in which the Jester has witnessed this phenomenon is when business school types make venture capital pitches. The Jester is surprised not to have noticed it before, but there is a distinct tendency among ICT-for-doing-gooders to promote their projects in the same manner.

The Jester speculates that this happens for one of several reasons:

  • Some people are recycling some or all of their VC presentations, particularly in light of so much delusion about Prahaladian bottom of the pyramid.
  • Some people are recycling the presentations they made for the recent spate of dubious contests for mobile apps for development.
  • In the tweet-magnified ICT-for-good sphere, people come to think of every presentation as a VC pitch or a contest submission.

Even supposing that the underlying technology-for-good projects were worthwhile (a temporary supposition, the Jester assures you!), this is an abhorrent development. Other words to describe this phenomenon include lurid, execrable, putrid, detestable, loathsome, and whydontwealljustselloursoulstothedevilable.

Although the Jester appreciates attempts to make the world of do-gooding as efficient as the world of for-profiting, there are some very real differences. The for-profit world, for example, has a natural (eventual) check against pure bluster without substance, and that is the bottom line. In addition, the only people who lose in the for-profit world, if a start-up goes under, are the rich folks who bet on the start-up.

In the world of doing good, there is only a theoretical bottom line of positive impact. In practice, because impact is so hard to measure, rarely does impact figure in what receives support. Furthermore, there is an irretrievable opportunity cost when a bad project is funded over an impactful project.

Together, these two things mean that while in the business world, it’s perfectly ethical to pull all sorts of random numbers out of a hat and confidently claim them as the market potential, the world of doing good requires a bit more… doing good. More honesty and more humility.

Unfortunately, because social VCs and telecom competitions are judged by people drawn largely from the for-profit world, they bring their bad habits with them. Namely, they reward cleverness, confidence, and fake numbers over humility, genuine intent, and determination… exactly the opposite of what we want in good ICT-for-good.

So, what can be done? In a vain attempt to influence the juries of social enterprise competitions, and an even vainer attempt to influence the competitors, the Jester offers the following guidelines:

  • Above all, presenters should be up front about what is known and what is not known. Among the unknown, the process by which they might become known should be highlighted over attempts at speculation. Where speculation is necessary, the fact of its guesswork should be highlighted in neon colors. Judges should dock points for hollow confidence that comes ahead of real knowledge. Judges should award points for humility and interest in finding out the reality on the ground.
  • Presenters should highlight the role of organizational partners or efforts to build the non-technological requirements for success. If 80% of the effort is not technological, why should technology dominate the presentation? Anyone who thinks magic will happen without non-technological components should be required to do community service.
  • It should be made clear what stage a project is in. Those projects that are only planning to have impact should be presented and judged differently from those projects claiming a history of impact.
  • For projects claiming to have had impact, a good presentation should include evidence of concrete impact, lessons learned, and what open questions remain for the next stage. Judging should look at the quality of impact first, and scale second.
  • Early-stage projects will have limited evidence of impact. In its stead, there should be more discussion of open questions about what kind of impact is expected. Attempts to guess at the range of possilibities, the possible theory of change, what is known about impacts from related projects, should all be cast as question marks, and not exclamation points. Most importantly, the intended methodology by which open questions might be answered should be presented. Judges should assess the completeness of the list of questions and the plans to answer them, not skill in speculation. 
  • Presentations will presumably also include boasts about the technology, etc., but the less the Jester says about that portion of the presentation, the better.

Overall, judges should judge as VCs supposedly do — not for the idea or clever technology, but for the right qualities in the “management team.” For do-gooding, the key qualities are genuinely benevolent intent, determination with humility, and healthy respect for non-technological aspects of the solution. (For more along these lines, see the Jester’s comments on teaching ICT4D design.)


July 12, 2010

A two-and-a-half week trip to India was very productive for the Jester. He gave talks at an ICT4D summer school, spent quality time with friends and NGOs, and consumed six months’ worth of genuine Indian food, to make up for the six months since he was last there.

During this time, and in the synchronicitous ways of the world, the Jester encountered many groups of people who were tremendously excited about ICT4D. The summer school was attended by 70-odd students and would-be ICT4D-ers all eager to learn about ICT4D. And, many of the NGOs the Jester visited were beginning or continuing experiments with ICT4D. Although it was rumored that the Jester’s musings on “10 Myths of ICT4D” convinced one or two souls in the summer-school audience to reconsider ICT4D altogether, most seemed invigorated, perhaps in the manner of reckless, young, race-car drivers who taste adrenaline at the sight of crash and burn.

Their excitement was captured best by an e-mail the Jester received. In a strange juxtaposition of technological irony and global serendipity, the message was received while he was in India, but it came from America, and it was written by an Indian. The subject line announced, “Request for Guidance!” In it, the author (let us call him “Abhishek”) says… “During my final year at [university], I started to ask myself the question ‘What is the purpose/ultimate goal of my life?’ After a lot of thought process I came up with an answer like ‘do work which impacts the lives of millions in the poor communities’. What I am now trying to figure out is the suitable path through [which] I can contribute most effectively to these developing communities.” Earnestness like this, you can’t buy at a chai stall!

It turns out that Abhishek has recently joined a US technology company, but he feels that he can best achieve his purpose in life through ICT4D. Although there are some kinds of puffing-up the Jester enjoys deflating, he finds no joy in mocking sincere seekers. (Not much joy, anyway.) Too, it seems wrong to shut the gate on those who walk the path the Jester trod not too long ago. After all, as a great king of jesters once said, “The road of excess leads to the palace of wisdom.” What then, does the Jester say, to the excited ICT4D newbie?

Jump in!!! And, jump into direct experience, not piles of books, papers, and other second-hand accounts. The most important thing, if one is interested in impacting other people’s lives, is to become intimately familiar with what their lives are really like. If a picture is worth a thousand words, a visit is worth a million. Whatever it is, the Jester encourages any way to actually get involved with work that requires very close contact with the people one hopes to impact. This could be done in a number of ways, through volunteering, internships, jobs, etc. Many such opportunities are often posted on online websites (e.g.,, as well as mailing lists (e.g., the TIER mailing list: ), and a good fraction seek people with technical skills. The important thing is to sign up for an opportunity that involves significant engagement with poor communities – the more time with them, the better; don’t take a job that only involves coding in an air-conditioned office, especially if it’s in a rich city in the developed world. Then, once in the job (or internship or volunteer opportunity), keep volunteering for work that requires working with relevant groups. Find out as much as possible through questions, observation, living with them, etc. Do not complain to the Jester about language differences, cultural barriers, inconvenient weather, or guerillas brandishing guns. (Hmm, perhaps the latter are a valid reason for concern.) Where there’s a will, there’s a way. ICT4D intervention is a good entry point to development for those with technical ability. It can be used as a way to get an understanding for real development issues.

Meanwhile, the Jester recommends reading as much as possible about international development. Books, websites, papers, etc. Reading is valuable not so much because it describes what development really is (that sense – often a very personal one – is best gained through direct experience), but so that one becomes comfortable with the jargon and discourse of development. Among the most enlightening of writings is an obscure blog known as the ICT4D Jester. The Jester recommends reading every post. Thrice.

In short, ICT4D is the perfect entrance for technologists interested in development. (The key phrase here is “for technologists.” For those coming from a development background, the Jester says, “Abandon hope, all ye who enter ICT4D!”) It offers a means to engage with the complex, multi-faceted endeavor of development, while allowing a technologist to contribute a little technical support here, or a bit of electronic innovation there. ICT4D is a broad perch from which to learn about development, because technology’s tendrils can extend into every domain of development, whether it’s education, agriculture, microfinance, governance, livelihoods, gender issues, et cetera.

The Jester thus encourages a foray into ICT4D for technologists, albeit with the hope that wanderers will not stop there, but continue onto even more meaningful aspects of development. For technologists, ICT4D is a step in the right direction. (The Jester only requests that those taking this step remember his Golden Rule:  If your goal is to accomplish something in development, then work with people who are already doing competent work in development; then, apply your technical skills to support those people.)

Blind Man’s Design

April 28, 2010

The Jester has recently been involved in a number of ICT4D classes. These are all well-meaning courses with respected faculty teaching them. They are also all located in the United States. For anyone hoping to teach practical ICT4D skills, such as design or entrepreneurship, this latter point immediately brings up a question: How does one teach practical ICT4D skills at a university that is inconveniently located thousands of miles from Africa?

In this post, the Jester discusses interventionist projects in which the goal for students is to design or prototype technologies, or to write business plans or grant proposals for new ideas. (Note that this post does not discuss academic ICT4D, in which the goals are to cram student brains with language-obfuscated journal articles and to teach them to spout incoherent jargon. That can be effectively done in a classroom even on Mars.)

As a problem faced by wealthy professors teaching rich kids at elite universities in developed countries, it might not be among the most pressing of issues in development, but since these courses are often the first indoctrination of the next cadre of idealistic changemakers, it seems important to set them off in the right direction.

The wrong direction is to make young impressionable minds design solutions for environments that they don’t know anything about while sitting in first-world classrooms and libraries, and then to pretend that they’ll have learned something useful without actually implementing anything on site. This all-too-frequent exercise in ICT4D design and business classes, is effectively asking students to practice what the Jester calls Blind Man’s Design: Attempting to solve problems one’s never encountered for people one’s never met in places one’s never been to. Blind Man’s Design is a lot like White Man’s Burden – arrogant, misguided, and ineffective in bringing about meaningful learning. Actually, it’s even worse if a lucky good idea comes out of these exercises, because students then learn the wrong lesson – that you can devise good ideas in development without a clue.

The right direction is to ensure some sort of immersive experience, ideally where sincere attempts are made to implement ideas “in the field.” The best designers and the best entrepreneurs have great intuition for their customers. How does a person develop good intuition for an environment she’s unfamiliar with? She spends time in the environment. She gets to know everything she can about it. Most importantly, she feels its vibrations until she can tap the rhythms herself. That can lead to a good gut feel for the “real” problems and for real demand, as well as the myriad constraints that a design has to navigate. There is simply no substitute for good intuition in design, and there’s no substitute for time spent physically in the environment to gain good intuition. Anyone who says there are even reasonable approximations to firsthand experience has a bridge to sell.

In particular, the Jester notes that reading case studies of successful design-for-development doesn’t count as knowledge (even if they’re written by as august an intellect as the Jester!), any more than readers of books about Google have real insight about what it takes to be the next Larry Page. Steve Jobs never took a formal course in design, and Bill Gates never finished college. What they know, they learned directly from their personal interaction with their market. Mathematics students have to do proofs on their own; English literature majors have to read actual literature; budding anthropologists have to spend a couple of years living among the natives – why should ICT4D intervention be any different?

Unfortunately, not every ICT4D course conducted in a wealthy country can afford to send all of their students to a developing country for an immersion experience. There are constraints of money, time, and other classes. Plus, not every student taking such a course will be committed to seeing an intervention through.

The problem is not, the Jester stresses, that someone who’s never been to a poor community could never design something valuable for that community. Exhibit A is the mobile phone, which was more or less fully formed before anyone considered them for poor communities in developing countries, and yet it’s perhaps the most successful ICT4D ever (the Jester believes this fact will hold even until his death). Sometimes, good design for rich human beings has value for poor human beings. No surprise – good design is good design, and poor people are people, too. But, if the goal is to nurture generically good designers, presumably there are generic design courses for that.

No, the problem with Blind Man’s Design in ICT4D courses is that it reinforces the bad habit of rationalizing decisions made in the absence of real data. This is a cardinal sin in development. Better to admit you don’t know and that you’re guessing. The Jester sometimes repeats himself when he worries that people didn’t hear the first time: The problem with Blind Man’s Design in ICT4D courses is that it reinforces the bad habit of rationalizing decisions made in the absence of real data and experience.

Design projects inevitably include phases where faculty and students whittle down brainstormed ideas, discuss them, critique them, or attempt to pick “the best” idea out of a bunch. If done by people unfamiliar with target environments, all this does is to reinforce everyone’s badly formed preconceptions, as the Jester has seen in student competitions where teams defend their Blind Man’s Designs to probing judges whose own credentials in ICT4D intervention are questionable. This is often worse with the brightest students, because bright students are spectacularly good at rationalizing in the absence of data. Inevitably, this kind of interaction teaches people to get attached to their own bad ideas, to become proficient at defending baseless decisions, and to believe that a made-up justification is better than acknowledging, “I don’t know.” That’s how the road to hell gets paved.

Many professors who teach ICT4D courses have had years, if not decades, of formal training in buzzwords like “appropriate,” “contextual,” “ethnographic,” and “human-centered,” all of which place a premium on knowing the customer right down to how many hairs they have on their left pinky knuckle. Many instructors also realize – deep in their hearts, if not in their syllabi – the hypocrisy of having students design solutions for groups they have never even interacted with. Yet, they feel compelled to run these courses – maybe they feel it’s the most they can contribute given their own expertise, station, and the golden handcuffs of academic tenure in a developed country. So, what is a well-intentioned teacher to do in the absence of a healthy travel budget? Here are some practical ideas from the Jester, for what could be done in lieu of a Blind Man’s Design project…

  • Do a project for a local, poor community. Of course, the reality of poverty will be different from place to place, but the methodology of how to go about it, and the experience of unexpected challenges will all apply. Important meta-lessons can be learned. As a bonus, a recurring class can develop an ongoing relationship with local partners. The Jester applauds Keith Edwards at Georgia Tech for going this route.
  • Run a wacky design project or an entrepreneurship project, without a focus on “D.” Again, there are meta-lessons in design and entrepreneurship that are worth gaining through direct attempt, rather than through bookish learning. Tina Seelig of the Stanford Technology Ventures Program has some great ideas along these lines. With some cleverness, they could probably be bent to have a little more of a “D” element. The project goals could be less about revenue and more about positive social impact, for example.
  • Establish ties with development organizations “on the ground” who have need for the kind of skills the course is attempting to teach, and let students do projects for them. The important thing is that the partner organization has enough understanding of the problem context, that it has the ability to provide real direction and feedback. There’s no point in taking on an outsourced design project from an organization that is itself at arm’s length from the problems. Likely, the more the project is specified by the organization, the better – while there will always be room for creative input, well-spec’ed projects are hard to find.
  • Take ideas generated elsewhere, and ask students to come up with questions that they’d have, if they were to undertake the projects themselves. Push them to ask any and all questions. The important thing here is to keep the focus on asking questions, and not on answering them. Any attempt at answering them without firsthand experience will, again, be brittle and empty.
  • If it’s absolutely critical to do a complete design/plan project (the Jester doesn’t understand why it should be, except that some academic tradition demands it), put the emphasis on the degree to which the students arrive at the right kinds of questions, and their strategies for answering them. When they make design decisions, stress that they are only guesses, and that what’s important is that they are explicit that they are guesses. Perhaps allow students to arrive at multiple designs, based on multiple possibilities. Don’t even bother trying to comment on the quality of any answers however they get them (unless it’s through actual trial and error at the location). Ask students to explicitly include words like “tentative” and “preliminary” in the title of their projects and throughout any documents they write. Grade students based on their thoroughness in asking questions, and plans for how to get them answered, as well as their explicit admission of decisions made tentatively and with suboptimal knowledge. Deduct points when they make assumptions they shouldn’t be able to make. Resist the great temptation to articulate judgements about the likelihood of the idea working, even if the idea stinks — the problem is that that then pressures students into trying to come up with good ideas on the basis of poor knowledge, instead of thinking through questions and the plan of attack.

All of these suggestions avoid what the Jester believes to be the big no-nos: to have students design their own ICT4D interventions prior to immersion, to build prototypes or business plans which they then rationalize and justify with nothing other than secondhand information, and possibly to have those projects critiqued and judged by faculty or “experts.” The reality is that no one knows whether something will really work or whether it’ll meet all the constraints until it’s tried in situ, not even when endowed with a spectacular intellect like the Jester’s. Why, then, reinforce such a pretension in class?

Pedagogy of the Professed

April 28, 2010

It’s raining ICT4D classes at universities, particularly in the United States! What used to be no more than a sprinkle of classes across the globe, is spreading quickly. As with ICT4D in general, multiple disciplines are contributing to the downpour. Computer science and engineering departments have ICT4D courses; business schools have social entrepeneurship classes; design schools have design-for-the-other-90% classes; and quite a few departments hold classes examining the activity of ICT4D under all manner of critical lenses.

This might be due to growing interest in global development from people who hadn’t thought about it before. It might be curiosity about ICT from people who have non-ICT development experience. Or, it might be recent ICT4D graduates trying to propagate their intellectual selves from newly gained faculty positions.

In any case, it shows that both students and faculty are eager to get into the game. Despite the Jester’s persnickety remarks, he believes this is a good trend, overall. Certainly, it’s a positive sign that people are interested in something other than building a new iGadget on which to polish their Facebook profiles. (The Jester believes gadget and social-networking fetishes to be a kind of pornography – turn-ons depend on minor variations of the same thing; libidos are the underlying motive force; and people spend all sorts of secret time on them. But, that’s a whole ‘nother story.)

But! It wouldn’t be very jesterly to raise the issue if there weren’t some problems, too. And, oh, how there are problems with ICT4D education! The Jester even considered a name change to the ICT4D Curmudgeon. He decided against it only because he likes jester’s hats. That, and he’s too cheap to pay for another domain name. Instead, he will dump relevant posts in the Teaching ICT4D bin.