4 Tips to Avoid Bus Factors and Have Better Software Maintainability
If you like this video, you can find more on my YouTube channel :)
Reference Links
Transcript
How to avoid the bus factor in software development? In today’s video, I’m sharing my experience in building a better workflow to prevent the pain and trouble brought by the bus factor.
Hi, my name is Adler, and today I’m sharing some tips for avoiding the bus factor. If you’re not familiar with the bus factor, it means that we have a project that only one or few people know how to develop or maintain. If these people are run over by a bus and need to take some days off, a project would get stuck.
Since it’s not limited to the software industry, if you have worked in any industry before, you probably have heard of someone quitting the job, someone else assigned to take over, and that person having a miserable time taking over the work.
Most of the time, it’s because we’re always chasing the deadline when we’re working on a project. We don’t have time to think about anything else, and as we become swamped, we don’t care about whether other developers could maintain this project or not.
But, if you think about it, avoiding the bus factor saves us time in the future. At any point in time, things gonna happen on a project. The project owner will quit, or that person will be assigned to another project. So, it’s better to start with the right method, which makes it easier when things happen.
The tips that I’m sharing are practical, but it takes time to implement. We don’t have to start a revolution in the team. They are mostly some good habits to keep in mind when we do our work. From there, we can build up a good workflow slowly and move toward a better state.
Number one. Follow coding standards and best practices. This includes writing readable code, writing unit tests, writing inline documentation, and performing code reviews. Each item is a big topic, so I’ll put some links in the description below for details. Or if you’d like to know more, I’ll explain in other videos.
When we follow a coding standard, it’s easier for other developers, including us, who will come back to the same code six months later, to understand better how the code works when reading it.
For example, it’s common that we have some bizarre business logic (I hope not) that cannot be understood when reading the code. We always have that reaction like, “oh my god, what is this spaghetti code here for?” If we have some comments on the function or at least a link to some reference documents somewhere else, it will be beneficial to the readers to understand the purpose of a specific piece of code.
Number two. Workflow Documentation. This is different from inline documentation within the codebase. We have to spend time writing some documents describing how to proceed with the project.
For example, how to deploy a new version of the app? How to install specific dependencies from a private server? Who to talk to if we have a question about our payment service provider?
This part would include troubleshooting. In my experience, it’s helpful to have a place to list all issues that we have in a team, either bug we don’t have time to resolve yet, and the problems we will see again and again.
The benefit? When we need to tell someone how it works, we basically can just send the person a link to the document and then continue to focus on our work. If the document is good enough, that person can finish it on its own. We won’t be bothered with any questions. It’s a win-win situation.
Before we move on to the third tip, if you like this video, don’t hesitate to hit the like button and subscribe to the channel if you want to see more videos like this one.
Number three. Responsibility Rotation
Responsibility rotation means that one developer works on project A, and another developer works on project B. After six months, they switch their responsibility and work on each other’s projects.
This might sound like a complete waste of time, but it’s not. This is more like a risk control, and we’re moving the time required for taking over the work when someone quits, to the time when it’s less urgent. If the developer rotated to project B has any questions, the previous developer is still there. They can have a meeting any time they want. But if the previous developer has quit, there is no one to ask.
However, this might be difficult to implement because everyone tends to stay in their comfort zone when being busy. I would suggest talking to a manager or tech lead to seek their approval before bringing this up in the team, which would make it easier to persuade the other team members.
Number four. Do not have a team that has only one member.
This is another management decision. But it’s crucial that one project or one service should be maintained by two or more members. This is not just for the bus factor. This is for general maintainability. Everyone knows it, but as we can see in the industry, there are still many services or projects out there that are maintained by only one developer. They don’t have code review, no inline documentation, and no workflow documentation. This is because there’s only one member, so no one else needs to read it.
Also, if technical decisions are made by the only member of the team, we’re going to see some very interesting choices. For example, for a new JaveScript project, are we using React.js or Vue.js? No, we’re using jQuery for everything, no matter how complicated a project is. This is essentially why we want a team to have more than one member. Maintainability comes from teamwork. Only when there are discussions decisions are made logically and reasonably.
If you are working in a company with one or more projects that only one developer is working on, I would suggest keeping this in mind.
Bonus tip. Pair programming
Pair programming shares the responsibility from a single developer to another developer. It is a workflow in which two developers code together to resolve an issue or build a new feature, typically using the same screen or doing remotely. It’s another big topic, so I’ll skip the details for now.
The benefit of pair programming is that responsibilities are shared when a program is created. It might take time during the coding process, but it saves time for the code review (because it’s already reviewed during the coding process). And it saves time for introducing or describing how the code works to other developers. It’s good for maintainability, avoiding the bus factor, and it’s good for having more interactions with our colleagues. Unless we hate our colleagues (oh...).
OK. I hope you find this video helpful. Let me know in the comment section below what other topics you would like to hear, and let me know if you have any questions. I will see you next time!
