On Wednesday, in my Software Engineering class, I learned that my classmates and I are going to create a contract for assessing our achievements in the course. I, in large, agree with my peers on their thoughts about a contact that will make this a successful course. In this post, I am going to reflect on my thoughts of different elements of the contract we discussed in the class. In the end, I will make some suggestions to what should be included in the contact. To begin, the contract is essentially a set of guidelines that my peers, and I can use to hold each other accountable. I have to say, the moment I learned about the “contract thing”, this course became my favorite. I do not believe that students should be assessed based on a pre-set grading rubric or criteria by the instructor. This only limits the potential of each student and does not account the fact that all students learn in a different way. But, if everyone creates a mutual contract upon which all are going to be assessed, then this eliminates the boundary of what each individual can achieve.
Communication is one of the most important elements of working in a team. The term can easily be disregarded in terms of its vagueness, but I’ll break down all the elements that go into effective communication:
Presence: One should be present during class times, and mutually agreed meeting times outside of class. They should inform their team members in advance of their absences and as soon as possible in case of an emergency.
Skills: To be able to work in a team properly, we need to know each others skills. If someone does not have a particular skill to complete a task, then they should tell the group in advance, and not wait until the deadline is close.
Progress: Everyone should meet at the beginning or end of each week to discuss their progress so far, and set new goals for the following week.
**Organization ** is another important aspect of a good software developer. An excellently organized work falls into the following element:
Style: Everyone should adhere an agreed style of commenting a code, spacing or tabs, and defining function inputs and outputs. This is a hard task to accomplish, but as a team to be able to be able to successfully release a patch, adhering to the style of the community is essential.
Documentation: It is also important to document the work done. It is often easy to get lost when writing so many lines of code. Appropriate documentation can help each member understand each others code and also help the community
These were some of the elements we discussed in the class, and I have provided my thoughts on what an excellent (or grade A) student should do, to make this class successful. We also talked about Goals, which is what we want to achieve. But, we were not able to finish the discussion on goals. So following is what I think about goals.
Setting **and Achieving **Goals: **This is probably, in large, would be the most difficult to do. In my mind, a successful team sets realistic goals to accomplish a task within a deadline. So, each team should break bigger problems into smaller attainable goals. Each member should assume responsibility for completing a goal in a realistic deadline. It would be best to select goals, where one’s outcome does not affect other’s goal (but, it might often be difficult).
OK, that was all great. But, how are we going to evaluate each other? __I think at the end of each week, each member should fill up an evaluation form for themselves and one for each team member. The evaluation could contain all the elements of the contract. (I am suggesting something very similar to labor evaluation forms).
**Now, what? **There is no end GOAL one can reach in this course. At the end of the day, the more work, sweat, time etc. one puts into the course, the more outcome they will enjoy.