Competition holds no place in a school project

School projects shouldn’t be a place where the competition stands. Everybody should have the space to express and learn.

Competition holds no place in a school project

During my Bachelor’s degree in Business Information Technology, I had a lot of different projects, whether programming-related or not. We developed web, desktop, or mobile applications.

I can’t stress how good those projects were, the difficulty went up gradually, and working with friends was a blast. But, as you can imagine, not everything was perfect, groups were competing.

I have nothing against the competition, it’s part of our lives and is — most of the time — right. However, competition has little to no place in learning; I will focus this article on the act of studying and practicing what you learn and not about other aspects of the studies that gravitate around the school, such as school ranking or prices.

Whether it’s social, economic, political, or cultural, you can find people race for nearly everything in life. Humans love to compete, and, since I’m a software developer, I’m just going to acknowledge it, this is a subject way too complicated for me.

What I’m saying is the following:

Because competition is everywhere, it should be subsequently good? Well, yes and no.

Why learning should be competition-free?

We know that we’re all different and that not everybody works the same way. Some learn fast; others are slow learners; some learn by trying, others learn by studying,… We all have our fashion of dealing with tasks, problems, manage unforeseen, or life generally.

This is for that reason that learning has to be done in a competition-free environment. Not because the competition is terrible but because studying is a personal thing. It’s the first time I had to work on school projects that complex with other people. Competition plus the group can submerge people in an accumulation of noise.

The focus of students will shift from mastering skills to adding features, from learning to organize the work to running through discussion, from taking the time to test the project to create an unstable mess. You get the spirit.

I didn’t realize at the time how unhealthy it was; we worked extra-hours to crush user stories down rather than trying to improve our core-programming competencies.

I can see arguments saying that working life is stressful and in constant competition, and this is correct. But this is working and not studying. Studying allows us to build the foundation of our future employment, and they have to be reliable. If that’s not the case, you end up with an unstable building. It also affects the self-confidence of students resulting in under-exploited talents.

Of course, not all problems can be tied up to competition; this is, nevertheless, an essential factor.

Subscribe to the newsletter to get new articles right in your inbox!

Subscribe to the newsletter

What caused the competition?

Nearly all our project began the same way, we had a kickoff lesson where our professor detailed the project, gave some wire-frames, a sparse list of features, and that’s it. We started developing right away. If some aspects weren’t precise, we could contact the professor to ask for his/her help. But that was it; we didn’t have to create a list of features, challenge ideas, discuss the project.

And that’s precisely what missed and what caused the competition.

Since we weren’t sure of some details of the project, we frequently talked between groups, and when some consensus was reached, the direction of the project was decided — forcing groups that didn’t take part in the discussion to comply.

This increased stress and created competition across groups; we weren’t learning but developing a feature to head the direction of the project or try to catch up with others. Sadly, I was often part of groups that lead this, thereby making me responsible for the competition.

Let’s imagine this situation occurring in a corporate environment. It would be crazy. The client would end up with a different product than the one asked — and, more importantly, paid — for. Pretty much anyone that has some project management knowledge can say that discussion is a crucial part of a project. So why not add this aspect to a school project?

Projects indeed changed a lot throughout the three years of my studies. In the beginning, they were simple and required hardly any project management; the objective was to practice programming. Yet as the semesters passed, the focus shifted to everything else but programming.

Why am I complaining, then? Well, because for me, the goal was still to develop, and not to hone in my project management skills. During our last year, we had to use tools that help teams organize themselves, yet this was viewed as a burden rather than an opportunity to implement an agile tool.

I didn’t get the memo explaining why I had to use those apps.

And for me, this lack of comprehension between the school goals and the students’ desire is the root of the problem. The fact that the programming we did was an “excuse” to make us master agile is something I didn’t understand at the time.

How to avoid competition?

While writing this article, I had one idea that could help schools reduce the competition we created. Since the latter occurred throughout programming projects, it would be interesting to provide a detailed product backlog during the kickoff meeting.

At the beginning of the bachelor, it would consist of a simple list of tasks, and as we learn more things about agile, we would be more involved in the establishment of the document up until the point where we have to do everything ourselves. The first projects we build are the same across all groups of the class; only one backlog has to be created. That’s only in the second half of the degree that projects are different; at that time, we will be able to produce our document.

This solution would help us understand the shift that is happening in the last year. By involving students more and more, it’s possible to focus on specific aspects of programming or project management that would have been overshadowed otherwise.

Moreover, this would eliminate all the decisions we took while developing. Because in the working life, no customer will accept something that wasn’t specified or correspond to the vision they have.

The grading would benefit, too; tasks could be organized in the classic MoSCoW method. In Switzerland, grades go from 1 to 6, and we can determine that developing all Must result in a 4 — which is the average — the Should in a 5 and finally the Could in a 5.5.

Why not 6, you may say? Because it’s essential to give students some room to experiment and try things. That’s why the remaining 0.5 can be offered if the project is well organized if the code quality is better than expected, or any other thing that the professor will consider valuable.

Working that way would put the professor in the position of the customer and prepare students for a more realistic approach to the development. By working in this manner, I would have more easily understood the importance of project management and the, now well known, shift that occurred during last year.

But is it enough?

I can’t ensure that my solution is sufficient to remove any competition in the class. However, it does eliminate the doubt that was caused by the lack of information we received during the first — and often only — meeting we had with the professor. In my opinion, that was the leading source of the competition, and mitigating this would vastly improve the atmosphere in the class.

I’m sure that there are a lot of other factors that create this competition and that my point of view can be questioned. That’s why I would be happy to discuss this with one of my professors or any of you that read this article — whether you suffered from the same problem or wants to challenge my take on the subject. I wrote this with the perspective of a student, and there might be many subtleties that I didn’t see.