What I learned about group projects

Those who plan do better than those who do not plan, even though they rarely stick to their plan.
-Winston Churchill

The ability to effectively work on a team is a vital skill for any software developer. Coding is often considered a solitary pursuit consisting of hours sitting alone in front of a computer screen. To some degree, this is true. However, a developer at any level is useless without the capability to work constructively with other developers to solve problems. It is, for this reason, I am grateful for the opportunities I have been given to work on group projects with other coders.

I have learned that group projects can be both rewarding and frustrating in many ways. Groups can always accomplish more than isolated individuals. Groups allow people with different viewpoints and knowledge levels to learn from each other. Groups also create a space for people to have fun, helping each other solve problems.

As anyone with experience working in groups knows, collaborative projects have their frustrations. Members dropping out in the middle of the cohort is a common problem. Missing members can throw the team’s plans into disarray. And of course, we are all familiar with the classic problem of people in the group not participating or participating very little in progressing towards the team’s goals. From my experience, however, the most damaging issues arise from mistakes made in planning or strategizing at the beginning. These mistakes often require midstream changes and rewriting of whole sections of the app.

These problems are especially magnified when collaborative projects are virtual instead of in-person. Without face to face contact, it can be especially challenging for people in the group to express their concerns. Misunderstandings and miscommunications can be more likely with virtual vs. in-person communication. Consequently, it can be challenging to resolve and prevent conflicts with virtual teams. Despite this, group software projects can be very successful despite their constraints.

Given all the problems that inevitably arise in group projects, I felt like sharing what I have learned so far in working on collaborative projects. Through my successes and failures in working on group software projects, I have learned some valuable lessons on preventing these problems. My failures and missteps have given me some insights into creating successful team projects. Hopefully, you can learn from my mistakes to increase the success of your future projects.

What to Expect

No matter how much you’re expecting it, it’s still unexpected when it comes.
-Jason McAteer

Personnel Changes

Members falling out over time is something very likely, especially for large groups. Members dropping out can be disruptive, as the number of members available at the time is a significant component of planning in the early stages. Each individual has unique skills and strengths. Just one member dropping out eliminates those unique abilities from the project. It can also be frustrating to pick up where someone else left off, leaving the group to finish someone else’s work.

Consequently, the group or project leader should expect the eventuality of a member(s) leaving. We are only human. As humans with normal lives, we have commitments outside the project. Emergencies or family commitments arise. Life goes off course. Beyond this, we often realize we are taking on more responsibilities than we can handle. Given this, the team should plan for a reduction in numbers over time.

Spotty Contributions

In an ideal world, all members of the group would take on an equal burden of completing the project based upon their unique knowledge, talents, and abilities. Real projects rarely follow this mold. This divergence from this ideal is a source of great annoyance to which any project veterans’ can attest. The uncomfortable truth is that the group member’s contribution levels often follow the 80/20 principle. 80% of members make 20% of the contributions, while 20% make the remaining.

Changing Project Scope

The worst outcome for any project is to be nearing the deadline and not being anywhere near a completed functional app. The team should avoid this outcome at all costs. It is a prevalent mistake in project management to underestimate the time duration of tasks. It is also natural to underestimate the amount of time left in the overall project timeline. To mitigate this, keep the project scope flexible. If the project scope is fixed, focus on completing the minimum requirements as early as possible.

Broken Code

All collaborative projects contain the possibility of code bugs. If not detected and resolved early, these bugs can destroy an entire project. This is not hyperbole. Modern apps are becoming more involved with different libraries and frameworks interacting at multiple levels from front end to back end. Consequently, code in different parts of the app interacts in complex ways that can be difficult for one developer to understand. In a complex system, even a single bug can be difficult to isolate and address. The team should have a contingency plan for continuous testing and debugging.

What to Do

Luckily, the team can construct a strategy for preventing disaster. Many of the problems the teams face result from a lack of planning and communication. Consistent application of simple principles can have surprisingly positive effects on a project’s trajectory and ultimate success. Below are some tips for success based on my own experience working in projects.

Consistent Standards and Tools

Success isn’t always about greatness. It’s about consistency. Consistent hard work leads to success.”
-Dwayne Johnson

The project will not be successful if all its members cannot get on the same page. From the earliest stages, the team should agree on and understand the tools applied to create the app. Also, ensure that everyone comes to a consensus on the standards for writing code and making contributions. Put these standards in writing and let everyone on the team review them.

The following are some key points to keep in mind as you develop a plan.

1. The plan should include a naming convention for your git branches. This convention should identify what the branch is changing and how it fits into the project.
2. The team should agree on a protocol for commit messages. Each commit should be atomic, and the messages should reflect this.
3. On the team’s Git repository, leave the master branch for app deployment. Then, create a development branch for ongoing work on the app. Next, set up a protocol for working on local branches and merging them into the development branch.
4. Agree on a tech stack for the front and back ends.
5. Agree to a styling code for all languages used.
6. Agree on a CSS layout and naming conventions for classes.
7. Most importantly, agree on how to divide work between members and integrate contributions.

Ample Testing

No amount of testing can prove a software right, a single test can prove software wrong.
-Amir Ghahrai

Code can go wrong in a million different ways, and even slight changes can break an app. For this reason, the team should frequently test and verify the code at each stage. Critical points for testing are before merges and deployment. One of the worst things that can happen is making a long series of changes at multiple stages before finding a bug.

Have a plan for testing code for its essential features before any significant change. This plan should also require testing before any GitHub pull requests to an important branch. This is especially important to prevent merge conflicts. Additionally, the validation of code should evaluate the code both functionally and aesthetically. In other words, what the code does is essential; however, the code should also be well-organized and easy for other developers to understand.

Separation of Concerns

For every minute spent in organizing an hour is earned.
-Benjamin Franklin

Separation of Concerns implies at least three things:

1. The contributions from each member should be kept distinct and apply to different sections of the app.
2. The workload should be divided based upon the team members’ strengths and interests.
3. The code should be divided and modulated based upon a specific responsibility or task that fits into the larger codebase.

Separation of Concerns is a concept you’ve probably heard a lot about if you study computer science. It is crucial for many different reasons. However, to manage collaborative projects, its most important advantage is the organization. Keeping the code as well as each individual’s contributions well-organized and delineated is vital to smooth progress toward app completion on time.

Realistic Project Scope

First, have a definite, clear, practical ideal; a goal, an objective. Second have the necessary means to achieve your ends; wisdom, money, materials, and methods. Third, adjust all your means to that end.
-Aristotle

For any project, one of the most natural mistakes to make is to underestimate the time required for project completion. Most people tend to overestimate the amount of time needed for even simple tasks. I believe this partly occurs because it is easier to envision the completed goal and not many details. It is especially tricky to foresee the multitude of minor problems and mistakes that will inevitably arise. It is tempting to have ambitious goals for a project without a realistic assessment of the resources available and time constraints.

Deadlines are often pushed back several times in projects as the requirements and unexpected problems started growing beyond control. To avoid this problem, give the project ample buffer time by scaling down project scope in the beginning. It is much better to underestimate project scope and scale up later than to overestimate the workload leading to a substandard or incomplete app.

Open Communication

One of the most common reasons for project failure is a lack of communication. Especially with virtual projects, it is easy for members to lose track of each other and the progress of the project. To prevent this, have weekly meetings to touch base with all the members and their status.

Also, do not be afraid to confront any group members that may be causing problems early on. For example, ghosting is an issue that can be exacerbated by a lack of communication. By ghosting, I mean contributing very little if at all. The best response to this is an early response.

Beyond this, it is vital to keep a cool head. It is easy to fall into the trap of assuming the worst about weaker members. It is essential to not become accusatory but to handle the situation maturely. Group members often have personal issues that get in the way of contributing adequately.
Open communication is a great tool that gives the team space to set expectations early in the project. It is also an excellent preventative tool to stop any issues early on that could lead to veering the project off course later. Keep the lines of communication open is vital to the success of any team.

Key TakeAways

1. Expect the unexpected. Projects will rarely go according to plan. Stay focused and avoid getting frustrated by temporary setbacks.
2. Have an ongoing flexible plan. A plan, in the beginning, is essential, but continuous reevaluation makes the planning work.
3. Manage expectations for the project. Be realistic about what the team can accomplish with the given resources and time.
4. Open communication is vital at every stage of the project. Open communication leads to mutual understanding, cooperation, and a better-finished product.