Senior Project Reflections 1: Following the Life Cycle

Chirp… Chirp… Welcome back everyone, it took me a bit longer than anticipated to write this but I am somewhat glad that I took the extended break.

If you like excuses then heres mine: I took an introduction to philosophy class because I somehow skipped a general credit elective in the process of earning my degree in Computer Science. The reasons behind taking a philosophy class instead of something else include the fact that philosophy is interesting to me (due in part to me being a Christian and growing up enjoying discussing theology) and also because I find the philosophy behind Artificial Intelligence(AI) research very intriguing but was somewhat ill-equipped as to how to approach it. I also enjoy hearing other peoples perspectives because it allows me to understand what I believe better and to better round out the sharp edges in my beliefs. At any rate It was a very interesting class and I am very glad I took it, I really enjoyed discussing metaphysics and the aspects of AI with my classmates (it was an online class so by “discussing” I mean online forum posting). So the excuse is that this class along with working full time took pretty much all of my time and I didn’t have much left for writing and “reflecting”.

However, now that I have had all of three months to think about software engineering I am finding that the break gave me a good opportunity to distance myself from the biases of the project and do a fairer analysis of my senior project. So hopefully you will enjoy it as well.

I’ve decided to post several reflections of different parts of my Senior Project. So here is the first part with an undetermined number to follow:

When beginning to reflect on my senior project a specific incident came to mind, I was sitting at a Starbucks listening to some marketers talk about their boss and clients and how they disliked them. The end result (from my perspective at least, since they never actually stated this) was that they didn’t enjoy working as a team since everyone had unreasonable and unachievable requests. I can and will discuss some other aspects that I found interesting about the marketers discussion, for now however, I am going to focus on the aspects of team building and one way that I found life-cycles can encourage quality team development. I realize I have discussed my teams life-cycle model before in my post “The Importance of Risk” but I hope I am bringing to light a different aspect of the model here.

One of the things that I found absolutely amazing about my senior project team was in the weekly meetings that we had together. We would usually get together on Saturday’s outside of class and work on our current and next iteration of our cycle (we were using the win-win spiral model), but in these meetings (and throughout the whole class) we never had a project manager, a project lead, or a born leader. Every meeting we would get together and discuss things and at some point someone would go up to the white board and begin facilitating and organizing the discussion. This facilitator would differ from week to week and they never lead the discussion but simply organize what we where all saying so that we could find the finishing point of that meeting.

The nice thing about doing things this way is that it avoided the standard “group project syndrome”, where one person would become a self assigned leader, and a couple of people would do all the work and couple of people would do virtually nothing. This type of group seemed pretty consistent in all of my previous projects and seems to be a natural way for groups to form because of the natural desire for a leader. One major problem with this “group project syndrome” type of group is that it results in very little team gelling and causes people to end up on very large critical paths by themselves. This results in a dangerous type of project that may never have an “end”.

However one of the beautiful things of software engineering is the invention of various types of life-cycle models, this makes working on projects so much easier because in “modern” life-cycle models the model itself can be the project lead, and the members of the team can simply be peers trying to work out problems and collaborate while following the model. If used effectively and actually followed life-cycle models can lead to wonderful end results with very gelled teams¹. To some extent this happened with our team on the CBAA project, we would get together let the life-cycle model be the leader and then collaborate on the discussion of what needed to happen next according to the life-cycle model. Not having a person as a leader was a very important aspect that allowed our team to gel really well, no one was distinct or “special” in relation to anyone else which allowed there to be very little conflict over ideas and design issues.

By using the life-cycle model as the leader and collaborating with a team to come to a conclusion I was suprised by how many meetings ended with everyone agreeing and verbally saying “well its going to be tough but I feel good about it and I think we can actually accomplish this” and every meeting I left feeling very in sync with everyone else. This helped us to all know the direction that not only others were going but also the direction that the team was going as a whole. We certainly had things we could have improved on, many things actually, but I think that for only having a single semester we were able to accomplish quite a bit of positive team gelling through this collaborative effort and treating the life-cycle model as the leader.

---

1 – Tom DeMarco in his book The Deadline points out that although it goes against common business practice it is actually quite beneficial to keep well gelled teams togethor rather than separate them. The benefit being that once they are gelled they are much more able to begin projects in a good way rather than a rocky way, since they are already gelled and comfortable with each other.

My Thoughts on Modularity

A while back when Mozilla released Firefox 1.0 and I started to explore the extensions I was amazed at the basic utility that I gained from some of the extensions. This made me think about the methodology of Mozilla in developing Firefox, I was sure that they would add some of the extensions into the core code base of Firefox. When 1.5 and then 2.0 where released I was somewhat amazed that they hadn’t added any functionality that where in my favorite extensions into the Firefox core program.

My senior project is essentially to develop a new quiz type for the MOODLE platform. The M in MOODLE stands for Modular, unfortunately the MOODLE platform wasn’t developed with the same methodology that Firefox was. MOODLE comes prepackaged with several modules, like a wiki, forums, and even a feature rich quiz engine some of which are in the core code base. Since my senior project is to develop a new quiz type the fact that MOODLE includes its own quiz engine would seem like a good thing, possibly less work for the team I’m working with on the senior project.

I now understand why Mozilla didn’t add some of the Firefox extensions to its code base. In order to spawn creativity and encourage extension development the extension can’t already exist. The problem with including extensions, no matter how basic, in the core code is that if anyone wants to add on to the functionality of the software and a module/extension already exists then most likely it will share some of the same functionality and developers, rather than develop the new extension, will simply learn to live with what exists. Unless specifically asked for (like my senior project) when something already exists in the code base it simply stifles development of anything new that follows the same functionality line.

I will say that MOODLE is very modular and has several great places where key components can be added. The problem with MOODLE’s design is that it includes too many modules as standard code base items, meaning they have documented the fact that certain modules are part of the core MOODLE code base. This creates difficulties when developing a new quiz engine because it would be easier to add on to the quiz module rather than creating an entirely new quiz module. However, since MOODLE is open source we can use the existing quiz engine and from it create a new quiz module that is our own, the problem with this is that it creates parallel development paths. Anytime MOODLE updates the quiz engine we would have to extract, modify, and re-release our own module in order to allow for the full functionality of the quiz engine that we are developing within our new functionality.

So what’s the moral of my little story? Essentially its this: when developing software that is designed to be modular/extendable make sure that you only develop the core code base, and don’t start adding new modules to the core code. Keep modular software modular. If MOODLE had left the quiz engine out of the core code base and marketed it as simply another module it would help but wouldn’t solve our problems. Doing this would however allow us to possibly work with developers on a smaller issue for development than have to look at an entire software package to be changed/modified. This is a hard thing to do though, especially for MOODLE, since you want all users to be able to do standard tasks, like take a quiz. But the key is to keep modular software modular.  At least as far I’m concerned.