Posts Tagged ‘Group Projects’

It’s a while we are developing an interactive book application framework for iPad and the first book in these series is now right on App Store. Monkey’s Paw is a horror short story by W.W.Jacobs which was published in 1902. You can watch a demo video here.

Recently I took part in a group project. The time line was very severe and we were exhausted from our previous activity.

We started working with a rough design and split tasks. One day before the deadline we gathered to integrate our codes. My part included something unfamiliar, complex and tremendously unpleasant. After 5 hours of pulling out my hair off my head, I managed to do that. Now only a few lines and it would be finished. As I was very tired, I decide to pair program this part to avoid errors. My partner and I did that in a few minutes we had and then released the code.

When I was preparing my code for the main event, I realized something was wrong. Some couple of hours led me to an obvious error. A single line that was placed 4 line above it’s correct location!

Well, this bug was found too late and rendered all our results based on the code unreliable and false. So the project failed.

Under the following circumstances, it’s not recommended to code:

1) After over 8 hours.

2) When you’re too tired or distracted.

3) Whenever you cant concentrate.

But it’s sometimes unavoidable to w0rk in some (or all) of these conditions specially when you can’t appoint the deadline yourself.

Then, what measures are to be applied to prevent errors and bugs that may result in a total failure?

I’ve come to the following methods:

1) Test each and every module you write.

2) Spare additional functionality in favor of reliability.

3) Have a firm and clear time line for testing.

What you pay vs. what you gain:

Testing is time consuming and requires extra effort. Most times you are writing parts that get input from other unfinished parts (e.g. written by other team mate). This means that to test them you need to provide test data. But the extra time pays off! Tested part lets you focus on other parts and give you a good idea where to NOT look for it, saving up some time debugging and probably prevents some undesirable results.

In the future posts I’m going to explore major testing methods as well as the ways proposed by some well-known SDK’s such as eclipse and Visual Studio.

Post Mortem is when you discuss what happened in a project after it’s finished. It literally means done after death or after an event (definition from merriam-webster).