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!
No comments:
Post a Comment