A Mobile App Maker In The Extreme

The Extreme North of Cameroon is aptly named for a variety of reasons, apart from being the remote northern terminus of the country. It is, in many respects, a land of extremes with a vastly different character from the Grand South. Situated at the edge of Sahelian Africa, the climate is typically hot and arid with dry season temperatures reaching highs of 118°F (48°C). During this period, the rain ceases to fall in any appreciable amount for months on end, replaced by Harmattan dust whipped up from the depths of the Sahara Desert. When the rains return, bone dry mayos (rivers) and plains are subject to flash floods that may displace entire villages. Lacking any viable roads linking it to the south, travel to the region is achieved only by booking a flight on a small plane (fast and expensive) or an overnight train from Yaoundé followed by an 8 hour bus trip (slow and affordable).

With all its challenges—the climate, geographic isolation, poverty, poor infrastructure—it’s about as unlikely a place as any to find a nascent mobile software scene.

Until Djorwe Temoa arrived, that is.

Born and raised in the village of Tchatibali, Djorwe traveled to study at the prestigious National Advanced School of Engineering Polytechnique in Yaoundé. Degree in hand, Djorwe began his career in 2001 working for Orange, a leading mobile service provider. After his success in the mobile industry, he returned to the Extreme North with his wife. Following BarCamp Cameroon, Djorwe asked if he could visit Limbe Labs to get a copy of the iPhone SDK (at a whopping 2.3GB, a download well beyond the grasp of most Africans).


While he copied a trove of Mac OS X software to his external hard drive, Djorwe demonstrated two mobile apps he’s developed for the local market. I assumed that Mac users were rare in Maroua and aspiring iPhone app developers rarer still, so I was eager to hear his story. Djorwe was happy to oblige. The highlights of our conversation are below:

BZ: Tell me about becoming an entrepreneur with a focus on the mobile platform.
DT: I wanted to start my own IT company but I thought it required a big investment. Later, working with Jean-Francis [Ahanda], who was very interested in Open Source software, I discovered that it doesn’t take too much capital to start a software business. I also wanted to create software that most Cameroonians could use, which is why I chose the mobile platform.

BZ: And you’ve got a strong interest in the iPhone now?
DT: I’m interested in developing for the iPhone, but it’s very expensive. I know I won’t get one million subscribers in Cameroon with an iPhone app—not now. So I started with J2ME and SMS applications because more Cameroonians can benefit from them.

BZ: Describe for me what it’s like working as a software entrepreneur in Maroua. Are there others like you?
DT: I work from home. I can say, I don’t know anyone else in Maroua making mobile applications. As for the environment, it’s very hot—especially in March and April. So the best time for me to work is during the night. The good thing is it’s calm, so there’s no distractions. For an internet connection I use Camtel 128k ADSL, but it can go down for 1-2 days at times.

BZ: I couldn’t help but notice your new MacBook Air. I’m sure those are rare items in Maroua.
DT: Yes, they’re not common! (laughs) I bought the MacBook Air from a shop in Douala because I’m interested in building applications for the iPhone. Also, it’s a gift for myself.

Just when I think I have the software landscape in Cameroon pretty well figured out, a guy like Djorwe comes along to turn all my assumptions upside-down. If iPhone development can be done in Cameroon’s Extreme North—about as harsh a computing environment as one is likely to find anywhere—it opens up a vast range of potential footholds for software engineering elsewhere on the continent.

Djorwe is in Yaoundé as I write this, returning soon via train to his home in Maroua.

Avoiding the Zone of Suck with the 80/20 Rule

effort-payoffMost people are familiar with the concept behind the 80/20 rule or Pareto Principle. It generally states that 20% of a population consumes 80% of the resources. It’s attributed to a 19th century Italian economist, Vilfredo Pareto, who realized that 80% of the wealth in a given population was concentrated in the hands of 20% of the people. Pareto referred to this inequality as the “Vital Few” versus the “Trivial Many.” This observation has since found its way into numerous disciplines, including logistics, management, inventory control, biology and (you guessed it) software.

Put another way, 80% of something can be accounted for by just 20% of the total possible reasons or causes for it. One common adage in the IT industry is that 80% of all end users typically use just 20% of a software application’s features. In software testing, 80% of observed errors are often caused by 20% of the entire pool of known bugs. And so on.

Depending upon who you ask, the 80/20 rule cruelly predicts that in every human endeavor effort and payoff are inversely related.

At Microsoft, the 80/20 rule was treated like gospel and frequently cited by software testers, engineers, group managers and even the CEO, Steve Ballmer. Microsoft applied the 80/20 rule to everything from balancing DHCP server usage to analyzing crash reports for Windows and predicting how Chairman Bill Gates would divide his time between Microsoft and the Gates Foundation.

In a memo to his employees, Ballmer wrote about an epiphany he had with his company’s error-reporting tool:

One really exciting thing we learned is how, among all these software bugs involved in the report, a relatively small proportion causes most of the errors. About 20 percent of the bugs causes 80 percent of all errors, and—this is stunning to me—1 percent of bugs caused half of all errors.

Applying logic to this statement, the inverse must also be true: 80% of the bug-free functionality is produced by 20% of the code.

If this is true, then software engineers—not just at Microsoft, but all engineers—are writing an awful lot of crappy code.

Enter the Zone of Suck
A similar distribution exists for the requirements of a software project. The project manager knows this well—it’s their job, after all, to understand the full set of requirements, keep a project on track, on budget and delivered on time to the satisfaction of the customer. The project manager’s mantra for their team, therefore, is to focus on the 20% that matters. I wish I had a dime for every time I’ve heard this phrase uttered during my career.

Every software team knows that projects begin with a set of requirements and proceed through a series of steps where the original specifications are compared with the end product for completeness and acceptability. Without going into the various software development methodologies, generally speaking it’s a process of refinement and revision. During each revision, if the requirements of the process follows a Pareto distribution, a few key issues will bubble up and need to be addressed, while old requirements will gradually fade away. Here’s an example Pareto distribution for a software project:

Pareto chart

The left vertical axis is an arbitrary measure of the importance of a requirement while the right axis indicates a cumulative percentage. To apply an 80/20 rule of requirements management to a project, two lines (above) are added to indicate the 80% cut-off between the significant few, at left, and the insignificant many.

Another software adage which bears emphasizing here is that, in a given project, the first 80% is easy while the last 20% is hard. Early in the project life cycle, decisions are made about things like the choice of platform, database, data model, programming language and core functionality of the software. These decisions, once made, very seldom change. As with all things, the devil is in the details.

As one who’s worked for big software companies, small software shops and startups, it’s nearly always attention to the last 20% that makes a software project “pop” or fall flat. The engineer may report that they’ve coded the first 80% of an application according to the specification, but if the last 20% is rushed or neglected then code defects, poorly implemented features and performance bottlenecks can kill a project. Budgets are exhausted, deadlines missed, the customer is unhappy and the engineers are fed up. At this stage, the project may be said to have entered the Zone of Suck. It’s a place no one wants to be.

Failure to identify and respond to the last 20%—the significant few—near the end of a software project’s life cycle is what separates a usable, elegant, high-performing application from one that, well…isn’t. In the case of web applications, the ones that fail to impress usually reveal a similar set of problems: lackluster user interfaces, sloppy CSS, poor usability, missing features, slow response times and so on. Too often, shortcuts are taken to rush a product out the door and this critical last 20% (i.e., what the customer notices and expects) suffers as a result.

A Better Alternative
If we accept that the 80/20 rule has some merit, then it’s possible for software teams to anticipate the last 20% and avoid the Zone of Suck. Proponents of the Agile software development methodology will tell you that their principles are ideally suited to anticipating the last 20%. They’ll further tell you that changing requirements, even late in the process, are welcome so long as they satisfy the customer. Happy customers lead to repeat business, referrals and more revenue for the software makers. For startups, it can mean the difference between securing a second round of funding, a major liquidity event, or a lot of unhappy users and investors.

Regardless of which development methodology is used, a software business should never tell the customer, “it wasn’t in our contract,” that something which is clearly an oversight is “expected behavior,” or that it’s okay to release a beta version product with 20% of the bugs outstanding. This points to a major failure and is the quickest way to develop a poor reputation and kill off any hope of future business or funding.

Being involved in a winning software project feels great. The project managers, engineers and client are all stoked. If you’re lucky, the end-users you’ve designed it for will love it, too, and your application attains the Holy Grail of web software: the hockey stick moment.

The good news is it’s possible to change, if your team is willing to listen, engage with the customer and commit to the last 20%.

iYam.mobi – Africa’s Mobile Directory

ict4d mobile zambiaIt’s no secret that mobile devices are the predominant mode of telephony in almost every African country. In a continent of one billion people, the number of African mobile subscribers today is estimated to be around 300 million, representing a penetration rate of roughly 30%, according to the Africa Telecom News Mobile Factbook. With the popularity of handset sharing in smaller communities, the actual number of Africans using mobiles is likely to be higher, with growth rates that continue to outpace North America and Asia.

Africans increasingly depend on mobile telephony and information technologies for both social and economic interactions. Pan regional giants MTN, Vodacom, Orascom and others, together with smaller regional telecoms, are rolling out 3G and EDGE-based mobile data services to their subscribers. Despite this, handheld devices with Internet access remain a comparative luxury for most Sub-Saharan Africans. SMS is still the most popular, and affordable, non-voice value-added service. Meanwhile, broadband penetration in Africa continues to hover at around one percent.

Given these factors, wouldn’t it be nice if there was an intuitive method for mobile users to find, connect and interact with one another?

The First Mobile Mobile Phone Directory
iYam.mobi logoThis was the question posed by Fritz Ekwoge, the enterprising coder behind Kerawa.com (interviewed on this blog and profiled here). He noted that there was no mobile phone directory in Cameroon, not to mention for most of the continent. Without an easy way of contacting businesses in his country, Fritz set to work prototyping Africa’s first mobile mobile phone directory. That’s not a tautology, Fritz points out. His new directory service, iYam.mobi, is purely SMS-based, which means that any handset is capable of creating a profile and querying the iYam directory with a simple text message. Thus, it’s the mobile directory that goes everywhere you do.

iYam is a targeted, wholly appropriate solution designed specifically for African mobile users. It’s also the sort of service that, after using it the first time, leaves you wondering, “why didn’t I think of that?”

I was fortunate to give iYam a test drive during the private beta, along with Erik Hersman and others. During this time the iYam prototype was running on a modest hardware platform consisting of a pair of Samsung mobile phones connected to a laptop with Bluetooth. My impressions are given below. The service enters its public beta today.

Using the iYam Directory
The beauty of the iYam directory is its simplicity and ease-of-use. Since the service is entirely SMS-based, getting listed in the directory is as easy as sending a text message. iYam permits you to use only 155 characters to describe yourself. With this constraint, you’re forced to make those characters count. Twitter users are already familiar with this concept.

Fritz sent me a pointer to some simple instructions on using iYam’s service. Less than a minute later my profile was registered in the iYam directory and searchable by anyone in Cameroon—or Africa, for that matter. I simply composed the following SMS:

…and sent it to iYam’s MTN number. iYam replied with an SMS indicating that my profile had been created. Next, I sent a request to iYam to see who else was listed in the directory. This took the form of the straightforward query, “find engineer limbe” which returned an SMS with the contact information for the top five software engineers in my area. I found several new people who I might then contact for an impromptu meetup, or hire for their services.

Directory results are returned as an abbreviated list of names and corresponding phone numbers. Want to view someone’s profile? No problem. Simply send “whois [number]” to iYam and you’ll receive additional details for that individual or business. The fourth and final command you can send to the directory is “me” which returns the profile associated with your mobile number.

Thoughts on iYam’s Future
Needless to say, the potential for this application is huge. I demonstrated iYam to friends and business owners in my neighborhood, all of whom grasped the value of the service immediately. The first response from nearly every Cameroonian business owner was, “how do I get listed in the directory?”

Currently, finding a product or service in Cameroon depends on local knowledge, referrals from friends, luck or some combination thereof. For example, searching for a specific laptop model in Douala may involve an exchange of phone calls and text messages with a half dozen well-informed friends. Imagine instead sending “find laptop douala” to iYam and getting a list of results back. One might then send an SMS with specifics to each of the top five business listings and receive replies on pricing and availability.

One obvious usability question has to do with accessing paged results, as the directory currently returns only the top five listings. Fritz indicated that he’s heard several suggestions for how to handle this, so expect to see an update in the near future.

There’s the bigger question of how to shape iYam into a business. Erik Hersman tackled this side of the equation with Fritz in our email exchange, so I’ll defer to him in his parallel coverage of iYam.

That the service requires nothing more than a low-range mobile phone and SMS is perhaps its greatest strength. This was clearly borne out by the informal product testing I did with local Cameroonian business owners. People genuinely appreciate that a computer or Internet access isn’t required to create a profile or query the directory. It’s a powerful democratizing service built on an inexpensive, familiar, widely available device.

I think iYam also succeeds in just about every way by capitalizing on the philosophy of small software, in which a competitive advantage is gained from the unique challenges posed by Africa—challenges that are typically perceived as hindrances rather than conditions for innovation.

Fritz reports that availability of the service will be 20-24 hours every day during the week, and 24 hours per day on weekends. Beta testers in Ghana, Gabon, Niger, Benin, the UK and Cameroon have tried the service so far. With increased usage during the public beta, Fritz says he will scale the hardware accordingly.

iYam currently operates from two servers: one for MTN, and a second for Orange. MTN requests are served by iYam MTN (00237 7487 3391). Orange requests are served by iYam Orange (00237 9626 5496). International numbers are served by iYam MTN.

The Virtues of Small Software

Essayist, poet and philosopher Ralph Waldo Emerson had this to say on the subject of beauty:

We ascribe beauty to that which is simple;
which has no superfluous parts;
which exactly answers its end;
which stands related to all things;
which is the mean of many extremes.

- The Conduct of Life, Chapter VIII, Beauty (via TinyApps blog)

Doug McIlroy, one of the founders of the Unix tradition, may well have drawn inspiration from Emerson when he summarized the Unix philosophy with the following three tenets: “Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.”

This philosophy placed a special emphasis on the use of a large number of software tools—small programs that could be strung together through a command line interpreter using pipes, as opposed to a single monolithic program that includes all of the same functionality.

An approach like this worked well because, in the late 1970’s and early 80’s, programmers had to work within the confines of relatively small and expensive resources. While difficult to conceive of today, 16KB of RAM was common and 64KB was considered expansive (I remember writing my first assembly program on the Commodore 64—I thought I was in heaven). Likewise, storage in the megabyte range was a luxury. Programmers created small software with tiny allocations of storage and RAM that ran on processors that were Lilliputian by today’s standards. Every byte and clock cycle counted, and thus a lot of work was done to make programs fit into available resources.

The rise of bloatware
No bloatNowadays we have thousands of times the processing power, memory and storage yet, from the user’s perspective, software for the desktop, web and mobile seems to run slower than it should, or used to. We’ve been conditioned to accept long load times for applications, Ajax delays in Gmail, adware, automatic updates and the scourge of bundled third-party software.

Nathan Myhrvold, physicist and former CTO of Microsoft, once compared software to the physical properties of a gas for a keynote address in 1997. In a marriage of Moore’s Law and the Ideal Gas Law, he declared that “software always expands to fill whatever container it is stored in,” but its growth is “inevitably limited by the rate of increase in hardware speed.” So what happens when software hits the upper bounds of the hardware it’s contained in? Myhrvold’s response: “People buy new hardware because the software requires it.”

What Myhrvold succeeded in defining with his four Laws of Software, intentionally or not, is a Unified Theory of Bloatware. In one sense, his Third Law kept the PC business thriving by requiring bigger, faster hardware to run increasingly bloated software.

Moore's Law vs. installed disk usage of Microsoft Office and Open Office

In a challenge to Moore’s Law comparing installed disk usage of Microsoft Office and Open Office (see above), we find that, “at this rate of growth, Microsoft Office Standard 2013 will be 5000MB, and the Microsoft Office Premium Platinum Plus 2013 edition (a larger edition than the Standard edition) will come on a set of Blu-ray discs.” The take-home message: “Microsoft Office Standard edition’s growth is more closely in step with maximum disk capacities.” Myhrvold was right, at least insofar as Microsoft Office is concerned.

One of the best attacks on bloatware ever, Thank you, Adobe Reader 9!, comes from Ben Hoyt, one of a trio of Kiwi brothers behind Brush Technology. His post is acerbic, hilarious and gives Adobe a well-deserved thrashing as a prime example of what’s wrong with contemporary software. Ben posits the question, Can Modern Software Be Snappy? and draws on some examples from coding for embedded devices and graphics programming. Both are great reads on this topic.

Incidentally, if you haven’t yet please do take Ben’s advice and replace Adobe Reader with Foxit’s PDF reader. You’ll not only save yourself disk space and headache, but avoid some rather nasty security vulnerabilities at the same time.

Small is the the next Big Thing
In an ironic twist, with the rising popularity of netbooks and rapid growth of mobile devices as the default computing platform, software is returning to a focus on “do one thing and do it well” within the resource constraints of these small devices. Moreover, as consumers and businesses alike tighten their budgets during the global economic downturn, extending the life of old hardware is becoming a necessity.

The good news for end-users is that alternatives to bloat do exist. If you want to go really small, the single best resource for apps that run will run on nearly any PC hardware has always been at TinyApps.org. Peruse the list, try a few out (none is bigger than 1.44 MB and many are contained in a single executable), link them up with some keyboard shortcuts and you’ll be working smarter and faster than ever. Trust me, it works.

For the engineer, designing small software that can run efficiently with limited resources was, until recently, a dying art. One of the best resources for programmers is the excellent (and free) book Small Memory by Charles Weir and James Noble. You can also listen to the authors interviewed on Software Engineering Radio.

I’m probably preaching to the choir here, but along with this book it’s worth considering some small software maxims for the engineer. Among the best are Eric Raymond’s design rules in The Art of Unix Programming, Mike Gancarz’s The UNIX Philosophy, and Rob Pike’s Notes on Programming in C. They’re summarized nicely here.

Included with the “small is beautiful” software design ethos is an emphasis on performance analysis, code profiling and refactoring. Too often, in my experience, this step is sacrificed under time pressure to deliver a product to market, yet it’s a crucial phase of any project. Bottlenecks often do occur in surprising places and speed hacks seldom work without solid metrics. It also never hurts to run an app through a processor emulator like QEMU to get a feel for how it will perform on older hardware.

Implications for African software
Citing the challenges brought by bad governance, poverty, low bandwidth, and some of the harshest environments and use-cases in the world, Erik Hersman noted that, “If it works in Africa, it will work anywhere.” If “do one thing and do it well” may be said to capture the philosophies of Unix and small software, Hersman’s declaration is the battle cry for a legion of cottage industry African software entrepreneurs.

By adopting the philosophy of small software, the developers crafting solutions on the African continent are in a unique position to reap opportunity from their environment. Witness highly specialized, targeted applications such as FrontlineSMS, MobilePress, Kerawa, Afrigator, Maneno, Zoopy, Ushahidi and countless others—all created by Africans and distributed online, often for free. One of the most interesting recent applications built for the developing world, FrontlineForms, is targeted specifically at low- to mid-level mobile devices.

These applications (and a lot of others I’ve surely overlooked) are at the forefront of what Samuel Dean called a “knock down, drag ‘em out renaissance…involving guerrilla apps, widgets, and many other software offerings that don’t happen to come from Microsoft or other gorilla-sized providers.”

The future of software is small. The implications for Africa, and the developing world at large, are huge.

Kiva and the Case For Nonprofit Open APIs

Recently, Kiva announced the official launch of the Kiva API and a new developer website, build.kiva.org. This is a smart move for them, as freely opening up their micro-lending database both increases data interoperability with their partners and fosters the creation of useful and compelling third party add-ons. This extends the reach of their organization and takes their content in new, possibly unexpected, directions.

In fact, just within the last week three early implementations have already surfaced:

  1. Kiva WordPress Plugin – by Connor Boyack and David Miller. Released on February 4th, the same day the API debuted, this plugin is a simple and effective use of the loans API. Watch for this popping up around the blogosphere in coming weeks.
  2. KivaWorld – I’m a sucker for applications that make use of mapping, so this quick n’ dirty mashup gets a nod. Currently, it simply plots open loans as data points on a Google map. There are dozens of potential ways to extend this, including enhancing it with images, mapping relationships with lenders, partner organizations, historical data with loan return rates (perhaps by country/region) and so on.
  3. How We Know Us – Erich has done a fascinating data visualization of the Kiva loan network which appears to explore the linkages between lenders and borrowers. Like the previous two, this is an early effort but it already shows a lot of promise. It doesn’t require too much imagination to see something like this evolve into an interactive Flash-based tool for exploring interconnected data, alá Digg Labs.

These are only three early and admittedly rough examples, but they underscore the fact that open APIs like Kiva’s are here to stay. In fact, I’d say they represent the future. In the past, monolithic APIs were the exclusive domain of large, often proprietary software companies. Today, the standards and technology have both matured in such a way as to provide the potential for real richness in data integration, both within organizations, between organizations, and with bigger entities such as Google.

Using these tools, an engineer today can bring to market a lightweight, smart mobile app that leverages cloud computing and Kiva’s (or any other organization’s) data by mincing together API calls to create something entirely new and on a comparatively short dev cycle. This is assuming, of course, that the APIs are well-documented, well-supported, and truly open.

It’s natural that some organizations would resist the move toward opening up their data for public consumption, as it were. For one, there are (valid) security concerns. This always seems to be the first issue that arises in these discussions. However, speaking as a programmer, openness and security are not mutually exclusive. In fact, exposing and documenting an open API keeps a dev team on its toes and leads to more robust code in the end, in my experience. Ask any hacker to prove me wrong.

Another (less valid) concern has to do with losing control of how an organization’s data gets manipulated “out there” in the world. To this I’d simply point out that not long ago RSS feeds once presented the same concerns to website owners. A good number of content producers were slow to adopt this standard, fearing that syndication (and thus control of presentation, including advertising) would sound their death knell. They were wrong, of course, and today it’s unthinkable not to syndicate your content with RSS.

Open APIs often make good business sense in the case of for-profit, proprietary software vendors as well. Rather than concentrating on client implementations, they can instead focus on their core technologies and allow others to build entire businesses off of serving different vertical markets. For-profits with open APIs like Kintera, Salesforce and Convivo spring to mind.

Other examples of successful open APIs used in the nonprofit world? Comments are welcome.