Common Problems in Large-scale Website Projects and How to Avoid Them
Working on large projects can be a stressful affair. When you collaborate with more than 50-100 people, it is common for teams to encounter pitfalls that smaller teams do not face generally. Most of the time it can be due to poor management or lack of communication. But there are several other problems that crop up when large teams work together. In this post, I am going to list a few of them from a web-developer’s point of view, and how you can easily avoid them.
1. Inconsistent Code Style & Logic
This is one of the biggest problems large teams face. Not every developer thinks the same way. You can achieve the same result by taking different routes. This means your code can be different from your team-mate but has the same output. When another developer goes through this code, he has no clue how this code works.
Further, unit-testing can be useful in large teams. Reading through tests gives a better understanding of how a piece of code works. By unit-testing, your code gets more ‘debuggable’ and less prone to fail.
2. Missing Documentation
Developers write codes, run the tests, it works. But without good documentation, your code is still not bulletproof. In every large project, teams are further divided into smaller teams developing specific features. When those features overlap, these smaller teams need to collaborate with each other on a functional level. If you don’t have good documentation in place, the communication between the teams can be very difficult.
To avoid this, you can use one of the several documentation generators — docsify, docz, GitBook among many others. With these tools, you can generate documentation for your sites without having to write too many lines of code. Besides, these generators have a very gentle learning curve.
3. Communication gap between designers and developers
Nothing can wreak more havoc than communication gap between dev team and designers. Great designs can turn into a nightmare if you can’t bridge the gap. UI issues, if ignored, can pile up and be huge burden to fix on the long run. Designers may find very subtle difference between mockups and coded UIs but it’s the developers who need to pay attention and fix them.
To bridge this ever-increasing gap, consider using a component library. A component library is a set of reusable UI components, like navbars, forms, tables among others. Once the mock-up is ready, the dev team can break it down into small components and build around them. By taking advantage of a component library, both developers and designers are using the same tool. There are hundreds of UI libraries available online, Bootstrap being the forerunner.
Needless to say, frequent meetings between the two teams do help a lot. These meetings can be about UI reviews so that both the teams are on the same page. Or about sharing their visions about the product so that both the teams establish a clear understanding about what to expect from each other.
4. Using Different Toolset
Not every developer thinks and works the same way. Each one has their own choice of tools. But when you are working on a large project and you are using your own toolset, other than the one the team is using, the code-base is going to be hard to maintain. This kind of behaviour reflects lack of foresight and coordination.
Consider having a knowledge base. This will work as a central hub for project tools. If you feel you have better tool for solving the problem, stand up and speak for yourself. Yes, it may be possible that your ideas are not received well, but using a new tool without the knowledge of your team-mates, will not help in the long run.
5. Losing vision
Large-scale web development projects continue for more than 2-3 years. It is quite common for developers to lose focus. Large code-base tends to be monolithic. They are built by hundreds of developers. As a result maintaining them could be difficult. Pushing new features takes weeks, sometimes months. Focus is the first thing that gets affected.
However, you can stay focused and get work done, by simply being open to learn. Align yourself with the product vision. Take small steps. Coordinate with team-mates. Above all, as they say, the key is not to prioritize what’s on your schedule, but to schedule your priorities.
I understand that not all of the above can be implemented at individual level. We need to accept hierarchy. There may be several other problems specific to your situation. But taking small steps and remaining focused is the key.