Working with Remote and Overseas Teams
This particular project was a growing and learning experience in many ways. During this project, I worked remotely with an overseas team. While working with a remote team can be an enjoyable experience, it does present a few challenges. Those challenges are compounded when the remote team is also overseas. This project was no exception. There were many things that we could have done better.
However, there were many things that we did well.
The team communicated well despite the significant time differential. The PM would talk with them during their morning while I would talk with them just before they quit for the day. By doing this we were able to answer questions on both ends of the day without going crazy. In addition, we had well articulated tickets and goals which helped to increase our speed as developers.
We shared and distributed the tasks well. Allowing the devs to do what they did best and most efficiently. The overseas devs were competent and a joy to work with.
We handled tricky logic by creating new components rather than dumping the logic into the models and or controllers. When we first got our hands onto this application, logic strewn about the application in random locations was a real problem. We fixed the major issues right away and would refactor individual files whenever we touched them.
Along with this, we started implementing tests around new code and old code whenever we touched it. This proved invaluable as the project progressed given the complex nature of the application (it is a routing system with numerous constraints) and the need to refactor on a routine basis. Along with the tests, we also conducted code reviews, albeit asynchronously most of the time. Both of these allowed us to sleep at night for the most part though there were still a few monsters in the application because of the previous devs.
During this time we also eliminated several performance issues, particularly N+1 problems that were gifts from the previous devs. Even with query caching enabled a couple of pages were generated in excess of 100,000 queries, it was ridiculous to say the least.
On the frontend, there were so many calls and so much data retrieved that the system was almost unusable. Too many pages were not paginated and too much data was being retrieved that blocked the page load. We refactored many of these to make them more performant.
Lastly, we delivered a very complex application to the client in a short amount of time on a relatively small budget so that they could launch on schedule.
That being said, there were a few things that we could have done better.
Personally, I didn't do an awesome job with the code review process and cycle. While I provided good feedback on others code, I often would not make them fix their code since there was such a time difference, it was easier to make the changes myself. Except, it wasn't. When crunch time came, and it did, we didn't have time to let them fix their own issues so when they made similar mistakes it meant that I had to fix them. Obviously, this wasn't the best plan.
Along with this, we didn't maintain our testing discipline when it came down to crunch time. There were several requirements that were delivered late and as a result, there were several late nights right before launch. While it is difficult to think about testing your code while on a deadline at 3 AM in the morning, it is more often than not faster and safer to do so. This rule was violated in the name of speed (don't do it, trust me).
The requirements being delivered late was a definite problem, one that I had foreseen and commented on months before the deadline. However, I should have made a bigger and more frequent deal about it so that it remained at the forefront of discussion. I certainly paid for this with many long nights and frenzied moments leading up to the release. That being said, this was mainly an account management and project management issue. Not only were the requirements delivered late, there was a good amount of scope creep right at the end.
Taking the above into account, there are a few takeaways:
- Test, even in the middle of the night on a deadline
- People learn best if they have to fix their own problems
- Speak up early and often if you know something is going to go wrong