The Blog

“Calm down, madam, it’s just a rat bite.” My doctor friend had told the bewildered and totally shaken professor who’d been rushed in the ER on his dreadful night duty.

The elderly lady had dozed off in front of the TV after eating leaving her hands unwashed. Apparently, a bite had jolted her awake and the first thing that came to her mind was that she’d been bitten by a venomous snake!

Of course she and her folks thought my friend was totally bunkers to have even thought it was a rat! A bladdy rodent?! “Young man you must be an incompetent blah, blah, blah…!” her husband screamed. Threatening to report him to the “high and mightys” and ensure he was relieved of his job.

The woman was even having symptoms of a snake bite – vision problems, speaking and breathing trouble, and numbness! Well, in the end, my Doctor friend was right and they all (old and wise as they were) were dead wrong. The symptoms were somatization, simple hysteria. Funny, eh? I didn’t think so.

“Jus’ ‘cos am young, wear jeans an’ a T-shirt and drive fast, they think i don’t know my job.” He told me. It’s just a fact of life that the young are thought to be unserious, directionless and not worth the bother. (That’s a blog for another day though). But while he related his ordeal, he’d just described me and the rest of my colleagues. Young-gum chewing-jean and T-shirt wearing-back pack carrying clans who called themselves Developers, Designers, UX people, Network experts, whatever.

Once you said to anyone “Am into IT.” Be ready for one of two reactions:

(A) They start thinking “yep, sonny, excuse yourself for all the hours you spend fiddling on your computer and the internet at home while honest hard working people are either at work or asleep.” Or, my favorite,

(B) They  go, in their minds, “hmmmm, he’s making a killing robbing some organization(s) blind and keeping them in their ignorance of simple things and tools. Scammer! Legal fraudster!”

It’s, well, an occupational hazard that we accept, carry our laptops and trudge on.

But i am compensated, when i commute around the metropolis and beyond, to find the love that  users, both young and old, have for their mobile devices. Phones (Smart and otherwise), Palmtops, iPads, etc. A wise college girl once said “If you have your head raised high while all others are bowed, you should get a BB!” LOL! I’ll like to extend that saying, “… get a smartphone”!

Heads bowed, attention riveted to the glowing screens, fingers tapping out messages, people all over go about their daily businesses  dragging away their attentions when absolutely necessary and only for the briefest of times. Its a culture a fellow IT chap aptly named  ‘the Ratmode’. I agree the posture reminds one of a rat at work on a nut.

A GPRS enabled phone and a few bytes of data (as little as 10MB for about $0.67) and all troubles and sorrows melt away as users dive into the depths of online infotainment and communication Ratmode style. Social network sites are the first ports of call: Facebook, Twitter, Mixit, 2go, Nimbuzz, Badoo, etc. And I mean etc! Aha! lest I forget the classiest one in these parts, BBM. (I said it, so BB lovers, am on your side.) Aside the Social network sites, there are a million other mobile sites for stuff like music, movies, games, wallpapers, pictures, the works. Our loyal IM applications are never far away too.

It gladdens my heart, that with rat sized bytes, smartphones and applications, the www in a nut in the hands of the user. Africa has been split wide open to the ratmode culture, the internet penetration is largely experienced on the mobile.

The charts above reveal a fascinating trend and I can assure you that those figures are advancing daily in bounds.

Africa is going mobile! Nigeria is going mobile! Developers come up with fresh ideas and products to keep users interested and happy daily. Mobile Web? Bring it on. Mobile App? Let’s tango. Obviously, if you are not mobile, you are nowhere. Simple!

We IT folks are still easy to spot, from a few minutes to a few days observing us, it becomes obvious. Yesterday, a total stranger in a full commuter bus asks me to please help him upload a profile picture from his mobile device to his favorite social network platform! Damn! Spotted again.

From my desk on a rainy morning,

Greg.

Some years back when IT started taking a new shape within the ranks of paid jobs, every developer had to build all they needed from the scratch. While in some instances in my opinion, there might still be a need to go that line again, today’s participation most especially through the open source communities has taken application design and development to the tweak and plug stage.

Tweak and plug is my coinage for taking APIs here and there, doing basic restructuring to have them fit into your own app and you are good to go.

This is one phenomenon that has helped the IT professionals and indeed the world in general understand that sharing code base and/or technology doesn’t necessarily stand in the way of making money. On the contrary, such acts help expand your reach as many individuals from different parts of the world access your code, make use of your APIs and in the final analysis discover new things you are capable of doing.

Such discovery is about the most reliable way of getting people involved in major projects that eventually translate into wealth.

We do not have to run a day long debate to agree to this fact, cheap as it might appear. We almost all have had one reasons or the other to search through google for a particular tools for our personal use; I have and I am sure you also have.

Another aspect to a phenomenon that is generally referred to as open sourcing is that, you really don’t have to do the talking if you are sure of your applications and/or code base. They speak for themselves.

The term open source describes practices in production and development that promote access to the end product’s source materials. Some consider open source a philosophy, others consider it a pragmatic methodology. Before the term open source became widely adopted, developers and producers used a variety of phrases to describe the concept; open source gained hold with the rise of the Internet, and the attendant need for massive retooling of the computing source code. Opening the source code enabled a self-enhancing diversity of production models, communication paths, and interactive communities. Subsequently, the new phrase “open-source software” was born to describe the environment that the new copyright, licensing, domain, and consumer issues created.
Source

Several tools that are open sourced today and supported by big companies started like a child’s play; something no one but the developer and his few colleagues with their undying zeal believed it would see the light of the day.

These tools end up solving so many problems we either have failed to see or refused to confront and then become every developer’s companion.

Task as common as web design can now be accomplished from scratch to deployment with almost no input from the developer as it were, many more scenarios are there to confirm the far reaching advantages of open sourcing.

Here are few open sourced projects.

Python, Kodos Python Regular Expression Debugger, SWIG, OpenSSL, IPFilter, Xfire, Fiilzip, ZipGenius,

StuffIt Expander, Erlang, PHP, Tcl, Wavemaker, Bugzilla, Winmerge, XML User Interface,

Album Shaper, Gallery Project, PhpGraphy

Other developers have decided to open source their projects first for the reasons of lack of key resources like fund and time. While these factors seem frivolous to admit in other fields, for an IT person, it is worth the admittance because at the end of the day, few minutes from different developers across the globe who share the ambition of the pioneer developer stand up to the task and have a wonderful job that would have naturally died of neglect and lack of fund.

The open source concept has also in some ways helped big corporations support the profession by a way of funding useful apps and keeping such projects alive.

From the human point of view which is also my opinion, open source as an art has helped improve our relationship with one another beyond the walls of racism and boundary of travels. A German based developer might have his source code forked, and modified by an African, vice versa. We all at the end of the day work as a community irrespective of our location, colour, height or financial status. It also preaches the principle of collective responsibility and collective victories; this story is well understood if you read the acknowledgement pages of books on open source. You see situations where the pioneer developer almost goes home with no laurels as he has given all accolades to support developers whom ironically he hasn’t met before.

My take on this is that we all have a duty to give back to where we take from and also to understand that rewards lie mostly in giving than in taking.

We are the latest brides as IT professionals and we should take advantage to prove to the world that things can be done better as a community with emphasis on collective efforts and collective victory. It necessarily doesn’t have to start with you; identify an ongoing project that falls within your area of interest or strength and lend a hand.

The world, and not only our community as developers, would be a better place if we can approach our tasks from the open source point of view.

Back in the days, the waterfall model of software development was the de facto standard, however, the times have changed. Now there are numerous methods and approaches to software development and in some cases, minor dialects of the same development process. At TimbaObjects, we use an Agile development process that’s somewhat custom and so not as specific as methods like Scrum, XP or AUP. We use tools like Pivotal Tracker that helps us track and respond to issues as quickly as possible.

Here’s our typical process:

1. We sit with the client to collect requirements. This might be a new feature, a bug or modification on a certain feature.
2. We create tickets on our tracking system to reflect these features or needed bug fixes
3. We work on these features and fix bugs and
4. We meet with the client again for feedback

We continue this cycle until the project is completed. Pretty simple right? Well not exactly; if you’ve been accustomed to using the waterfall process, this is really going to move you out of your comfort zone. In our experience, no software project is particularly complete until the software itself or project expires. What more? Very few clients know what they really want from the start of the project. As the software project becomes a reality, there will be modifications in the requirements – some big, some small. Without an iterative process, this becomes a nightmare for both client and developer.

In our most recently concluded project, we used the Agile development process to really speed up turn around time for software delivery. In hindsight, we probably couldn’t have successfully executed this project without going Agile.

Project SwiftCount was quite an experience for me. I learnt a lot during the project, right from the start which was the development of the application tool itself, to the testing phase, the usage of the application tool, to the end. When I say I learnt a lot, I mean “I learnt a lot”, not only on the technical aspect now, but the experience that came with it as well. Infact in this blog post, I won’t make so much emphasis on the technical aspect, I would talk a lot about the experience I had.

First and foremost, I realized that a project usually ends up bigger than initially anticipated. Clients would only tell you “I want this“, they have no idea how complex their demands makes the deliverables become. I had an idea it’ll be big at the initial stage but I didn’t realize how complex it’ll get, it kept growing and growing and growing as changes were made to the application tool and new features were added.

For instance, we needed to know the status of each message coming in, we thought we should represent these statuses with different colors. The status colors were initially three;  green, yellow and read for “complete” “incomplete” and “Missing”.  As time went on, we realized that the three statuses wouldn’t be enough for the categories of statuses for the messages, so what happens when a message comes in and it is partially sent? Or what if a centre where the message is to be sent from does not open? How do we represent these new statuses with the previous three? So we decided to add two more statuses meaning we now have five statuses instead of three. As these changes were implemented, that meant more lines of codes and a little expansion on the application tool.

Secondly, I would say it is when end users are introduced to a product that you can tell how efficient it works. You can never tell if the product being developed has met up to its intended use if you have not introduced and involved the users to it.

Therefore it is advisable that for any software application being built, users should be involved throughout the development process. I’ll give an instance below.

During the training of data clerks, the data clerks were able to grasp the knowledge needed to use the application tool on time. This was because as the developers of the application, we were involved in the training of the data clerk. I’ll like to point out that developers are sometimes the best candidate to train personnels that’ll be using an application. The organization might have staff being trained to train these personnels, but it is the developers that has a better understanding of how the application works. Initially we weren’t assigned to train these data clerks, they were to be trained by their zonal coordinator, but when we thought about how important it was for these data clerks to fully understand how to use the application, we thought it would be best if we were the ones conducting the training. During the training, the application tool to the data clerks was narrowed down to the user interface. Now this is very funny because I thought that after all the coding and assembling of the application tool, it was just the ‘checklists’ and  ‘incidents’ that were the major area of concentration, and with help from the ‘dashboard’ as well, to view and track expected and recieved messages from centres. But from my own perspective, I knew a lot had been put in to make the application tool to make it what it was, I knew it was a lot complex than that.

What I’m trying to draw out here is; ‘Of course, it’s the duty of the development team to design a product that’ll meet user requirements, and no matter how large or how complex the development of a product is, all a user can understand about the product is through the user interface.’

Furthermore, I remember us having simulation days to test the application tool prior to the “big” days it’ll be used. On these simulation days, we would test the application to see how it’ll perform when under a lot of pressure, we would have observers send text messages from the field, as messages poured in we’d fix bugs and we’d work out kinks that we noticed. We would spend most of the day making sure everything worked well.  One would think all will go smoothly after these simulations but no, on the “big” days, there was always something coming up to be fixed. This made me realize that asides involving the users during the development of a product, no matter how much you test a product before it’s intended use, it is only when it is being used for the purpose of which it is being built for that you can tell how effective it is because it is then you’ll really get to see how it’ll perform under live pressure.

The “big” days for which the application tool was built for always had it’s high and low points. There were times when we had messages coming in and we had to stop the server because it wasn’t syncing due to the volume of messages pouring in. In such situations, we would be under a lot of pressure because we were working to make things go smoothly and the clients were under a lot of pressure as well, they would panic and would be on our case knowing we were fixing these intermittent issues arising as a result of the usage of the application being under a lot of pressure. But at the end of the day, we always went home fulfilled because things always ended very well.

(A tip here for you if you ever find yourself in such situation above, don’t let the constant yelling of  “you’ve killed the project, you’ve killed the project!!”  from your clients get to you. *laughs*).

Finally, it was at the end of the project that I fully understood the goal behind building the application tool. On realizing this, I was overwhelmed because we were carried away with developing the application tool, but we didn’t get to realize what our clients wanted to achieve with the results gotten from the application tool until the very end. Now don’t get me wrong, I’ll explain this. From the onset we were building an application tool to monitor a particular event. Very correct because that was the exact application we built, but at the end, the results that were compiled from the application tool was compared with the results gotten from a separate organization that actually handled the event on the field, meaning two separate bodies now comparing end results. When both results were compared, the difference between the two was very slight. We all know that when making comparisons, a 100% in such situation is not guaranteed, given that events were monitored with different methods, but 99%? Yes! It was at this point that I realized *wow* this is one huge project, and you know what?  We pulled it off successfully! *Beaming!!!*

It is not an easy something to experience “the experience” , it only prepares you for future challenges (*Now I understand why they call us “Terror Squad”…hahaha*).

Kudos to all my colleagues that were part of this project, at this point I say thank you all that has taken time to read my blog post. I hope you found it interesting. Thanks to the TimbaObjects crew, I’ll be back with another interesting blog post… Adios amigos!!!

Welcome to our newly revamped website. For some odd number of years, we’ve had what our friends call, a “banner” website and we’ve finally heeded their advice to run a proper website for the company. So here’s the fulfillment of that promise. Now let’s have some fun!