The Blog

My experience during Project 2011 SwiftCount

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!!!