# Remote Software Development - Lessons Learned

DevFeed: [Remote Software Development - Lessons Learned](<https://devfeed.tech/articles/remote-software-development-lessons-learned-24948.md>)

Original publisher: [Read original article](<https://codeahoy.com/2016/06/12/remote-software-development-lessons-learned/>)

Author: umer

Published: 2016-06-12T00:00:00Z

Content type: article

Language: en

Sources: [Code Ahoy - Articles](<https://devfeed.tech/sources/code-ahoy-articles.md>)

Topics: [remote-development](<https://devfeed.tech/topics/remote-development.md>), [Development](<https://devfeed.tech/topics/development.md>), [Code](<https://devfeed.tech/topics/code.md>), [modules](<https://devfeed.tech/topics/modules.md>), [Java](<https://devfeed.tech/topics/java.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [java](<https://devfeed.tech/tags/java.md>), [modules](<https://devfeed.tech/tags/modules.md>), [remote](<https://devfeed.tech/tags/remote.md>), [remote-development](<https://devfeed.tech/tags/remote-development.md>), [software-development](<https://devfeed.tech/tags/software-development.md>)

## AI overview

The author describes lessons from building a remote software development team while working on a replacement for a rejected product system. Tightly coupled code and poorly isolated modules made independent work, onboarding remote developers, and integration difficult.

## Source excerpt

Previously, I talked about the ill-fated rewrite of our core product. The 'second system', although better and faster than its predecessor, was rejected by the customer. But the story has a silver lining - one thing that we got right in the process that empowered us to grow and thrive: we built a highly productive remote development team. In this post, I'll share my experiences: how through trial and error (and with luck), we finally got the right formula and made it work for us. Part of the original system team was one of the best duct-tape developers I've ever worked with. We called him 'The Code Machine'. He didn't write clean code, but he wrote it fast as hell and made sure it worked. The original system, done with a gun to our heads, was a big, complex, monolith application and the boundaries between its modules were ill defined. Computer scientists refer to this type of code as tightly-coupled and the system is referred to as non-orthogonal. The 'second system' had a more grand vision and we needed to grow the team to build it right and on schedule. We hired another developer, a bright, young CS graduate to work on the system. One problem with the original system quickly became evident to me: because the code was tightly-coupled (the auto-generated UML class diagrams resembled a spider's cobweb), the new developer couldn't work independently: changing one part of the system indirectly impacted other parts. While they were not bickering, the two developers couldn't get out of each other's way and the progress was slow. Parallel to all this, the upper management decided to give 'remote software development' a try. Someone on the board recommended a company from Hyderabad, India and before I even knew it, I was interviewing a bunch of remote Java developers. The non-orthogonality problem was further magnified when the remote developer joined the team. Because the system was tightly-coupled, he was going to have to learn it all before he could become productive. S