Post BGP 2015 – What went wrong (part two)

Hello!

Continuing from the last post, here are the other things that went wrong with the BGP project (from my perspective at least). Note that I’ll be using the words ‘workplace’ and ‘office’ interchangeably when referring to the room that was set aside for my group to work on the project in.

Working hours & presence at the workplace

The working hours for the group were initially set, from 9:00 / 10:00 to 17:00 / 18:00 (some flextime was allowed). This would have been all well and good if everyone had kept these working hours. However, as time went by, people started showing up a later hours, usually after 12:00, meaning they had to stay until after 18:00 to get their work done for the day.

This meant that most members of the group didn’t work in the office at the same time. This makes collaboration more difficult. Working in an office that is mostly empty can also be quite stressful, as I realized far to late. You don’t know what the other members are doing and you have no firm grasp on the status of the project overall.

This became even worse when some of the members stopped coming in to work all together and worked from their homes instead. This was tolerated initially as it was believed that more work would be done faster if they were allowed to work at home.

In the end I believe it did more harm than good due to the lack of collaboration that resulted from the lack of presence at the office and the influence this had on the stress factor.

Failure to utilize SCRUM & daily stand-up

The group initially had SCRUM documentation set up as well as a daily stand-up routine, which was only kept during the first few weeks, after that the daily stand-up fell out of practice. This was probably due to the lacking presence of group members in the workplace. That most group members didn’t follow the working hours if they did come to the office made this even worse. The daily stand-up routine did come back into practice somewhat towards the end of the project with some help from the school, and it did help increase production but in the end was not enough, unfortunately.

The SCRUM documentation was hardly ever used after being set up, even at the start of the project.

This might have helped me keep focus on each task if I had stuck with it, but it is hard to say what impact it would have had. Even if I didn’t use the scrum I still documented everything I did as best I could in a diary of sorts as well as using the ‘sticky notes’ application in Windows.

Wrap-up

That is all I can think of. The problems were mostly related to stress and disorganization, not to mention having a team member drop out unexpectedly. What I took away from this was mostly the strong effect of being alone in the workplace had on my stress. Even if some people work better individually, they group as a whole will most likely suffer for it. It also makes it difficult to keep track on everyone through check-ups (or stand-ups) which may lead to additional stress and work being lost if the assets produced are not in concert with each other.

Cheers!

Post BGP 2015 – What went wrong (part one)

Hello!

I think I’ve been pushing this in front of me long enough now. This will be a bit uncomfortable for me to write about, but it needs to be done. Hopefully I can help someone avoid at least some of the mistakes that I and my group made during this project.

Lone programmer

The first thing I’d like to bring up is the fact that I was the only programmer on the team for most of the project as the only other coder unfortunately had to leave the team at the start of week three. The obvious problem with this is that I now had roughly twice the amount of work to do but no extra time.

Another problem that might not be quite as obvious (and a bit more difficult to explain) is the fact that I also had to plan the structure of the code all by myself. This meant that I could not focus my efforts entirely on what I was coding at the moment. I had to keep the entire code structure in the back of my head at all times, as well as the fact that I had to do all of it. Whenever I was working on one part of the code, say the movement mechanics, there was no progress at all in any of the other parts.

Yet another problem with being the only programmer is that you don’t really have anyone to discuss coding solutions with. You lose a lot of potential feedback. There were other groups of students that I talked to on occasion though. We also had something called quality time every week where I would meet one of the programming teachers and discuss development issues and potential solutions. This helped out a lot. In hindsight I wonder if I should have put more time into discussing code with students in other work groups.

Lastly, the fact that I became the only programmer in the group without warning also made things harder, as I had little time to adjust my code planning.

Bad pipeline

Before moving on I would like to point out that the pipeline I am talking about was my group’s production pipeline, not to be confused with other pipelines such as Unity3D’s rendering pipeline (http://docs.unity3d.com/Manual/SL-RenderPipeline.html).

The main problem with our production pipeline was that roughly half of the group’s members were not connected to the project’s source control until there was only one or two weeks of production left. Some didn’t even have the Unity3D engine installed on their computers until then.

This meant that whenever an art asset was made it had to be added to the game through me, which took time and focus away from programming. It also meant that if there was something odd with the asset when imported to Unity3D it either had to be fixed in-engine (by me once again) or I had to tell the other group members this after which another asset was made and then sent to me so I could import it once again.

This is obviously a very sub-par production pipeline, especially considering that I really needed to focus on coding. Once we got a proper source control going things went much smoother, but it was a bit too late to save the project unfortunately.

That is all I have for now. Part two should be up in a day or two if everything goes well.

Cheers!

Post BGP 2015 – What went wrong (prelude)

Hello all!

As you might have guessed by now the BGP project is over and it was, unfortunately, a failure. This is especially frustrating when considering the fact that it might well have been successful if we had one or two more weeks to complete it, but deadlines are deadlines. I will try to outline what I believe to be the main reasons the project was unsuccessful.

There is quite a lot to cover so I will divide this into several posts. The general outline looks like this:

• Lone programmer (part one)

• Bad/inefficient pipeline & source control (part one)

• Working hours & presence at the workplace (part two)

• Failure to utilize SCRUM & daily stand-up (part two)

I should note that this comes from my perspective as a programmer. I have heard about other problems on the art side of the project but since I did not work on the art in this project I feel that I should avoid bringing that aspect up here. I’ll leave it to the graphical artists that were part of my team to explain that if they so desire.

I should emphasize that this is NOT an accusation against anyone, even though it might seem like I’m pointing fingers at times. I will try to avoid this but I am going to have to talk about other members of my team in order to explain what could have (and should have) been done differently and some of the criticism brought up in this post applies to myself as well.

Part one should be up later today or tomorrow. Part two will hopefully be up not too long after part one.

Cheers!

Lack of updates

Hello all.

I realize that I have not been posting updates for a while now. This is partially due to the fact that I had to deal with being nearly burned out towards the end of may and start of june. I do intend to rectify this however. I am planning to write one or more posts detailing what happened towards the end of the BGP project in the not too distant future.

Cheers!