Don’t Implement On Passion Alone

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):

To hack or not infographic



Filed under A Category Other Than Uncategorized

4 responses to “Don’t Implement On Passion Alone

  1. Mark

    Hey Jonathan, quick question. Why does your infographic say “leave” when a person answers “Yes” to wanting to save the world?

    Maybe I’m just missing something but I gathered from your post that before you even consider undertaking a multi year project with a large scope you’ve got to be dissatisfied with the way things currently are. Doesn’t that imply that you want to change the world in some way?

  2. Hey Mark,

    What you bring up is a good point, and I would love to clarify. The problem with the concept of saving the world is that it’s a very large task, and that yes, wanting to save the world does imply a certain level of dissatisfaction with the status quo. But the caveat is that if you can’t realize the importance of placing your actions within a smaller scope, you are bound to become disappointed, and subsequently ineffective in your actions, for no one person can change the whole world alone.

    This goes back to the passion argument. I often witness individuals with passion for simply, “saving the world,” without understanding what it is they want to save in the the first place. To truly affect change, one must understand the complexities of the system within which he is working which requires what some passionate ones consider a significant and thus disappointing reduction in scope from the whole world to their local community. Realizing one’s own inability to affect massive change can quickly extinguish the flame of passion.

    If you cannot isolate what specifically you want to change about the world and incorporate it into a project suitable for your timeline, it may be better just not to come at all.

    Does that help?

  3. I can’t help but see parallels to a recent post of mine on appropriate aid vs. aspirational development – The gist: different scopes imply different timeframes, approaches & expectations. Perhaps an analogous formulation would be hack job vs. generalizable solution. The comparison isn’t a perfect one, but maybe there’s something there…

  4. Mark

    That definitely helps, thanks for taking the time to explain.