We had always wanted to build something relevant for elections in Nigeria and we had a lot of talk around this subject in 2011 when the last general elections in Nigeria were held but never did anything more than just talk about it. So when the 2015 elections were around the corner again, the talk came back but this time we were determined to get something done, anything!It all started with an excel sheet containing around 118,000 records, polling unit records from all across Nigeria. Since each polling unit record had a geographic coordinate, we were able to plot all the records on a map. Here is a map of Nigeria showing all the polling unit data (Google maps):

My boss suggested that we build a mobile app that people could use to share what’s going on at their polling unit during the elections. That sounded like a great idea and I set out to create a team to build the app. It was at this point I started seeing the challenges that would be faced and this helped in guiding me on what skills would be needed on the team. Some of the challenges I foresaw were:

• All the 118,000 records were in an excel sheet and needed to be cleaned up and pumped into a database management system.
• Since we decided to build a mobile app, we had to have an interface between the mobile app and the database.
• There was also a need to have a clean user interface for the mobile app, saw a need for good icons and images.

With these challenges and a whole lot more in mind, I knew exactly what skills I need on the team, I needed:

1. A database developer.
2. A web developer.
3. A mobile application developer.
4. Someone to test the app.
5. A project administrator to track/report overall progress and maintain the project documentation library.

Next thing was to come up with some architecture for the system, and we decided to have 3 major components:

1. A database, where all the data will reside.
2. A web application, to handle all communication between the mobile app and the database.
3. A mobile app, through which users would interact with the system.

DatabaseWe decided to use Google Cloud SQL to run a cluster of MySql instances. Our decision to use several MYSql instances was based on how we expect the system to be used, we realised that certain use cases required read only data while others needed to execute read/write operations for example, the part where users view polling units around them and search for polling units by tapping anywhere on a map of Nigeria only needed to read data from the database, no writes, so we decided to have that bit of the database run on a separate instance. For other use cases such as participating in a forum where users read and write comments we had that on a different instance as well.Web ApplicationThe major role of the web application is to expose a suit of web services to the mobile app. From the mobile app’s point of view this is all it sees. Since the web application is a JEE application we decided to host it on Google App Engine because we would enjoy automatic scaling as the number of users increased on the system*. Another reason we chose Appengine was because it has a blob service which allows us to store and serve pictures in a more efficient way than we could have if we stored pictures in MySql.We built RESTful web services and used JSON as the default for data inter-change.Mobile AppFor the mobile app we went with building apps for Android and iOS. The major challenge we had with this was getting good icons. Icons we had access to were not exactly what we wanted or how we wanted them to be so we had to improvise but again, we did not have a graphics designer on the team. At the time this came I remembered that I had had a brief exploration of graphic design in the past but I DO NOT consider my self a graphic designer, in fact people who saw things I had designed said they were horrible and honestly they were. Now, I knew very well that awesome apps have awesome icons so I did a little research on how cool icons were made (insert link). After a little experimentation here and there I was able to come up with these icons:

The mobile app had the most tasks that needed to be completed so we ended up putting three developers on the Android and iOS apps.MethodologyOur approach was to come up with use cases/user stories and then break each use case into tasks we needed to complete for that use case to become functional. For example we have a “view polling units around” use case which has tasks like “create user interface for viewing polling unit”, “build web service for viewing polling units around a given coordinate”, “Consume web service for viewing polling units around”, “Create a stored procedure for returning polling units” and so on. This meant we had to come up with an ERD, write some database scripts, come up with a list of procedures and web services and implement each one. We did this for every use case and iterated on what we had already built.After each use case was implemented we packaged everything and deployed to our test servers and asked our colleagues to download and try out the app while reporting any issues they come across. If any issue was reported we tried to recreate the issue in order to understand it better then we fixed it.Since we had a small team each member of the team had to document what he/she was doing and submit it to the project’s document library.

Building this app was fun and as with every project I learnt a lot of things, the team learnt a lot of things. The biggest thing we learnt was that it pays to have a working version of the software you are building from the very start no matter how few the features are, once you achieve that then you can continue to add features as you go along. I also noticed that doing this kept the team members motivated as they could see people using the app they built from the onset.

Here are links to the app: Google Play, App Store

Thanks to Anna Yusuf for reading drafts of this.