Subordinate Role Project – Implementation Phase

Hello! As promised, I’m back here to talk about the Implementation Phase of the 2nd Project.

First of all, I forgot to mention in my previous post that I volunteered myself to be Team Leader for this project. Since I have never done this before why not give it a try, at the end of the day we are here in school to try and learn from our mistakes (and experiences). So, my remarks from this experience were: I think I did a pretty good job being “the boss”; I was on top of things, keeping track of everybody’s work, sending communications constantly, requesting opinions when there were group decisions to make and programming my auto-assigned tasks.

On the personal side, there were a couple of things I need to work on (and I guess years in the field will help me with them). First, I need to learn to balance loads better, because especially when we were in the Design Phase I ended up doing more work than the others, but it was my fault, I happened to split the tasks that way. And second, I need to learn to rely or trust more on other people's work, because most of the time I ended up reviewing my teammate’s work just to check if things were right. This is not a big issue for a small project like this one, but when going large scale one cannot handle everything.

Now, regarding the Implementation Phase, my team was handled the Bucket Design. The Bucket Specification given by Keenan requested a Data Structure that could manage “Buckets of Items”: each Bucket should keep track of the Items contained in it, and each Item should know all the Buckets where it is contained.

It does not seem too complicated, right? Oh boy, I was in for a treat! I am talking about how different I could have designed a solution for this problem if I had been the one in charge of it (taking into account I come from the gaming programming side, not the software engineering one). To this day I still ask myself the following question: How do you go from the specification pictured above to the design diagramed bellow?

In  my  particular  case,  the  most  difficult  part  was  digesting  such  a  complicated  design  for  the  simple problem we were trying to solve. I do not know if it is because I always try to go the simplistic route first (complex stuff gets obfuscated in my head most of the time), but I think my mind had (and it is still having) issues trying to comprehend the reasoning behind such a complicated design.

I think this conflicting situation might be because I have a game-oriented programming mindset, therefore  I  usually focus on performance and straightforwardness rather than applying Software Engineering 101 Best Development Practices, and not by accident the given design was elaborated by a Software Engineering Student. Looking on the bright side, at least I got a chance to review and implement Hash Maps, which I had not used in while.

That’s how things worked out for this project. Stay tuned for details on Project Mayhem (3rd). Adios!

Subordinate Role Project – Design Phase

What up! I’m back here with some updates.

So, the 2nd Project is over (we are actually quite into the 3rd one right now) and I will try to provide a small recap on it. This project consisted on two (2) phases: Design and Implementation. The idea for the first part of the project was for my team to come up with a design that satisfies a specification provided by the professor and then we would handle the finished Design Document to an Implementation Team (not my team) for the next phase. Likewise, my team was handled another team's Design Document for the Implementation Phase, but more on that part in the next post.

In our particular case we were handled the Spin specification. This requiremeconsisted in a large list of items that could be rotated (spin) between two (2) provided indices. When I say "rotate" I mean that all items inside the given range are flipped in their ordering. In order to illustrate this better look at following provided example:

Well, my premise for designing was keeping things simple and close to the original idea stated in the specification, so after some debate inside the team we decided to go with my proposed doubly-linked list mainly because it provided the following advantages:

• Insertion (at the head and tail of the list) and removal of nodes can be done in constant time.
• List can be traversed forward or backward starting from either the head or tail of the list.
• Searching by node index inside the list can be faster since the operation can start from the end closer to the desired node.

I personally think we came up with a pretty solid and efficient design, and the package we provided to the Implementation Team was very detailed because it included: design overview, class diagrams, sequence diagrams, a suggested implementation schedule, test code and expected results.

Finally, and from the feedback we got from the Implementation Team, I can affirm you that my team’s hard work paid great dividends: the Implementation Team did not complain about the work placed upon them, and they contacted us no more than a couple of times (and were just clarifications), so this is how I would some it up “The more time you invest in producing thorough and fault-tolerant design documentation, the less time you will probably spend fixing possible bugs when the implementation phase comes in (support)”.

I will be back really soon with comments on the Implementation Phase of this project. Adios!

Unit Testing Project

What’s up everybody! I’m back with more cool stories about my Global Software Development class. This time I will talk about my Unit Testing Project. Prof. Keenan assigned groups based on our skill set (everybody in the class had to fill out an online survey) and the main idea is that you never meet with your teammates in person; you have to use all kinds of collaboration and communication tools to discuss and come to agreement with your team.

So for this project we were given a Physics Library written in C# and .Net and we (my team) were supposed to code some unit tests for it. I had done Test Driven Development before, but I have never actually written the tests myself, so I was kind of excited about this project since I was going to learn a pretty useful tool.

This project was divided in two (2) phases, so let me try to explain how they went:

The first phase of this project was all about Planning & Team Synchronization. First Julie, one of my teammates, proposed herself as Team Leader and we all gladly accepted. Next, we created a Google Group (forum/mailing list) to use as our main way of communication and we built a Team Wiki Page (Google Sites) to post team info, news, project development and announcements. Finally, we all had to go through the code using something called Cyclomatic Complexity and choose 4 different methods for each member to write Unit Tests for. Each one of the methods selected had different difficulties according to the value given by the tool. These were the methods I selected:

• Basic (2): AdvanceMath > Quaternion > Inverse (line 562)
• Intermediate (3-4): Physics2DDotNet > Shape > CreateCircle (line 88)
• Advanced (5-6): AdvanceMath > MathHelper > RadianMin (line 71)
• Expert (7+): Physics2DDotNet > DistanceGrid > TryGetIntersection (line 79)

The second phase consisted on actually Writing the Unit Tests. I didn’t know that C# and .Net had a library for doing this (another new useful tool for me, sweet!), but yes they do (Microsoft.VisualStudio.TestTools.UnitTesting) so kudos to Microsoft. The whole idea with these tests was to prove that the methods selected work as advertised, so we had to try and test their functionality using regular values and corner cases. Here is a screenshot of how Visual Studio presents the results:

Well, everybody in the team did a really good job and finished their tests before the specified deadline. So great work guys, this first project was smooth sailing. I hope the other ones go this way too. =D

Perforce's beginner mode no more

What up! Another week is gone, another assignment is done and the next one is already posted and due in three (3) days I think. So, here I am posting about the second assignment. Just like this class is supposed to be (not too much programming), this assignment was more about learning how to use advance features of Perforce than actually programming.


The idea behind this assignment was to create a C# console demo app in a series of steps defined by Keenan in the instructions. The program initially consisted of a Singly-Linked List that holds some numbers in each node. Then, I had to transform the list from Singly-Linked to Doubly-Linked and look out for some particular nodes and delete them. Coding all these steps was not a particular challenge, I have spent a good amount of time coding Linked List in previous Keenan's classes.


The important lessons learned from this assignment were all the unknown-to-me Perforce features I was forced to use. Here is a small summary of some of them:

• Delete and Rollback: one of the steps was to forcibly delete one file from the depot and in the following step recover it. I don't know if all Revision Control Systems work this way, but at least Perforce does keep a copy of all your files in the repository even if you selected to delete some of them. Then, using the Rollback option you can go back to a previous undeleted version of the file or folder it was contained in.

• Branch: another great option that Perforce offers is branching. This feature allows you to create parallel versions of files and folders that can be edit separately. You might be asking yourself "What am I going to use this feature for?", imagine that you want to try out a series of new features in a piece of software but you are not sure if you want to incorporate them in the final version. Well, you can create a parallel copy of the current version of your software and work on those features separately without interfering with the main line of code.

• Merge: this feature is basically the "opposite" of branching. Therefore, it allows you to merge or combine different branches into one. Using the same example as before, after you have coded and tested the new features of your software and you have decided that they should be incorporated into the main line of code, then you use this option on Perforce and with the help of the Conflict Resolution Tool you combine the parallel versions of the files and folders into one.

Using what Perforce calls Revision Graph, here is an example of how the different versions of one file look after using all the features mentioned above.

Well, I hope this information was somehow useful. See you soon. Adios!

Welcome back from the holidays!

After almost a year and a half without visiting my country I was back there for over a month, good times! Now is back to reality, back to long sessions of keyboard crunching, back to Keenan's awesome classes.

This time I am taking Global Software Development, a class about remote and distributive development. We will work with people in other parts of the world developing projects assigned by the Professor. The idea is to learn how to: be a subordinate (follow instructions) and a leader (give instructions), merge different parts of a project into a final piece, use communication tools (video conference, e-mail, IM, etc.), keep up-to-date documentation and journals of our projects, and more things I don't remember right now.

For our first week, Prof. Keenan gave us a really simple program to develop: a fibonacci sequence calculator. Don't worry, things won't be that easy down the road, this was all about warming up. The only important thing to note about this assignment is not to fall into the trap of coding fibonacci as a recursive function. Why you ask? I'll let you give it a try and you tell me later. You should code fibonacci using an iterative algorithm like the following one:

     int a = 1, b = 1;

     for (int i = 3; i <= n; i++)

     {

          int c = a + b;

          a = b;

          b = c;

     }
     return b;

I hope my post was helpful! See you soon. Adios!