For the past year or so I have been helping in various capacities, from friend to advisor to consultant to on-call technician in order to implement a technology solution to enable Kenyans living in rural areas (little access to electricity being our main definition of rural) to access information technology and the World Wide Web. This is a very broad role (and a very broad project) because I started with it when it was just in incubation (in it’s second form at least; the first form being disrupted by Kenya’s post-election violence), and work with the project today in its current form, which is the Rural Internet Kiosk down in Ukunda.
While working on this project, from concept to implementation, one key lesson that has been reinforced repeatedly is the need for local individuals to come up with local solutions over time and not let passion dictate long-term decisions. When implementing a technology (or engineering) solution, you have two ways to go about it: you can either, “hack it,” which just gets it done for a very specific task in a very specific way, or you can generalize it, which makes the solution applicable to a wide variety of situations. Hacking it can be a very short process and can create a solution that is excellent for a specific area, but may not easily expand. Generalizing takes a lot more time, and a lot more resources. It is with differentiating between the two processes that I have encountered problems.
It has been my (albeit limited) experience that many development-oriented individuals (development referring to profit not for the sake of profit, that’s business, but profit for fulfilling an individual’s basic needs), are extremely enthusiastic and passionate about their work, but also bring along a sense of urgency, possibly stemming from contractual limitations or from the passion itself (dare I say, passion breeds urgency?). When you combine this sense of urgency and passion with a desire to see a solution expanded to many areas, the situation starts to break down. Passion and urgency are great motivators to just hack a solution together and make it work but expanding a solution to a larger scale requires generalization. Generalization and urgency never go together, leaving many a development worker in a conundrum.
Instead, generalization requires years of product testing, labels such as, “alpha,” “beta,” “prototype,” or, “pilot,” and most importantly, patience. Passion and enthusiasm alone just don’t cut it. Passion can make things, “just work,” a great hack solution, but only if you keep your scope small. Here’s a tip: changing the world is not a small scope. Sometimes, changing even just changing one person is not a small scope, depending on what you want to change.
Here’s a case example. Let’s take one of Kenya’s technology-related, success-story, poster children: the Ushahidi crowd-sourced information platform. When Ushahidi was rolled out for the 2008 post-election crisis, it was very much a hack job, being put together in just a few days. The power of passionate coders is an amazing thing sometimes. But rolling it out to other situations was not an easy task, requiring teams of experience individuals to make new instances a reality.
Over time, the team has worked on generalizing their platform, and now, two and a half years later, they have reached what is considered a major milestone in software generalization: plug-in architecture. Now, not only can one easily create their own instance of the platform, but they can use the software’s built-in tools to expand it, without needing to communicate with the original creators. Ushahidi has the power to become even more unique and tailor made for specific locations, allowing the cycle to start again.
What is important to realize is that the two solutions are not mutually exclusive, as demonstrated by Ushahidi. It’s critical to make projects work quickly because it will motivate more people to follow your idea and build a continuous support base upon which you can then begin the work of generalizing. Far too often however, projects begin implementation with a 10 year goal, but no six month goal. I am not suggesting anyone leave their passion at home should they ever decide to help (no matter where or what the nature of that help may be), all I am saying is that one should not let their passion blind them to the simple nature of project implementation: quick solutions will never be quickly generalized; act accordingly.
I have provided a nice infographic to aid in your project implementation decisions (click for full-size):