Improving software quality in short term group projects
Introduction
How does one work in groups and create quality software? This is a question many developers have asked and we certainly could have benefited from knowing the answer. I will attempt to address how to improve the quality of software in this article.
The Project
In a meetup group GDG Memphis we were tasked with creating a budget app. The details of what this meant and how to implement it was left entirely up to us. I was put in a group of about 5 people of various programming experience from new to professionally employed. I had not met these people before and had two hours to work with them to create the web application.
As a side note, if you have not used meetup.com for finding programming groups I would highly recommend looking into it. I’m not sponsored by Meetup I just think it is a good way to network.
The Problem
So there we were in our breakout room, no plan or familiarity with each other, but confident enough in our skills. We began with trying to come up with a plan. We ended up using a whiteboard app in zoom to come up with a basic design. We did not come up with any implementation details at this point. We also decided to use bootstrap to build quick CSS styles.
As we started the code few questions were asked and everyone worked on their own part of the project. It was difficult to think of how to implement my section without knowing how the other parts would work and how they would expect my part to work. I knew something was wrong but felt the need to push through anyway. Now as I look back, I can easily point out some of the issues that led to our eventual end result.
Issues:
- Lack of specificity in our plan
- Not coordinating our efforts effectively
- Lack of a plan to ensure quality
- Lack of a plan to ensure consistency
In hindsight, many things could have helped resolve the issues and allowed us to come up with a more usable working web app. Here are some solutions I have come up with. Feel free to share your own approach to solving these issues in the comments.
Possible Solutions
Measure twice cut once/ Determine quality metrics
The old saying in woodworking is just as true in software as it is with cutting wood. For code to be clean and effective, it must be sufficiently planned before the code is written. There are many ways of doing this. For a small project, a small requirements document or design document could go a long way. In planning make sure everyone is on the same page. You want some form of written plan everyone is committed to before you begin. One way to make sure you are all on the same page is to have everyone come up with separate designs and explain them to each other.
The quality metrics you choose could be many things but there are likely just a few that you will want to really focus on based on what the project is and who it is for. For example, if you are working on a project that needs to work on many platforms and browsers then portability may be high on your list. If your project is small and only intended to be used once then portability may not be as important. You then consider these metrics and seek to measure them as you are writing your code.
Create an MVP
MVP stands for Minimum Viable Product. It means that you start by putting together the absolute minimum functionality to be able to meet the requirements. The requirements are whatever your end users’ and stakeholders’ minimum expectations for the software are. If the code is just for your group then perhaps you are designing for a future employer who may look at your code. Then when you have the MVP working, you can start to try out your ideas, make it look nicer, and make it more user-friendly.
Test your code
In our case, we tried writing the HTML CSS, and JS simultaneously. With the HTML not yet written it was impossible to test if elements would actually be added to the page. If you cannot test your code you are basically coding blind and that almost always leads to poor code. Test your code constantly by making sure it acts as you expect it to every few lines. Not only will this give you peace of mind but avoid a lot of headaches for your team later on. In addition, a good practice is to write tests such as unit or regression tests representing the requirements that fail before you write the code to fulfill the requirement. Make these tests your motivation for the code you write.
Improve communication
There are very few things you can do well in life without good communication. Pair programming is a good tool to keep programmers connected. As one writes the code, the other critiques it and relays information to the group. If you can break the team up into pairs it will allow for more people to communicate at once. Regardless of whether you do pair programming make sure your team knows what you are working on and how your work is progressing. One way to do this is to have a group Kanban board and move the user story you are working on through the board as you make progress on it.
You can also improve communication by leaving creative ideas and adaptation for after you have a working MVP and confirmed the idea with your team. Instead, stick to your team's design and requirements so you can create the MVP. Be pragmatic, sticking to the practical issues instead of the theoretical ideas.
If you have a question you can’t seem to find the answer to or code you are struggling to write, then ask for help. Don’t expect someone to read your mind or code. They have their own work they are focusing on.
If your gut says something is wrong, stop coding and speak up. It may be that others think something is wrong as well but have not spoken up either.
Remember you are not the end-user of the code. What you want may not be what is needed. You need to come up with the design of the code as a group for everyone to be fully committed to it.
Conclusion
In essence, quality software in small group projects can be improved by having a united vision, starting small(MVP), testing your code, and communicating impediments. Effective programming groups plan enough so they are on the same page when they get to the nitty-gritty coding. To start small build the least functionality. You don’t want to get to the end of your project and not have some form of working software to show. Write your code only after you have written tests to make sure it does what you think it does. Create a plan of action together on how you will communicate with your group throughout the project and stick with it. If you stick to these guidelines and think of some of your own you are much more likely to end up with something closer to the fancy working result you imagined your group would make.
Group projects are a great way to simulate real software jobs and are bound to have some issues especially the first several group projects you join. However, don’t let the difficulty of working together keep you from group projects outside of schooling. Instead, embrace those projects and give your team a good step forward by helping lead your team to produce quality software from the very beginning of your project.