A bit of background

I very recently began working at a software development company that has grown very, very fast. Its profits have grown tremendously, its employee count has grown, its project count has grown, and even the amount of buildings it owns has grown. From the outsiders perspective, this is a great thing. When talking to those that are in charge of the business side of things (sales, management, hiring, etc..), everything is going just as according to plan; however, the tech side of the company definitely has a different story to tell. The company has grown so rapidly, in fact, that the technology and routines of the company cannot keep up with the ever-changing environment that the company lives in.

A Quick Example

Take, for instance, version control. This is probably my biggest gripe about how the company operates. The company consists of many, many teams doing many, many different things. None of these teams can agree on a single method of version control. Each team does something different with their own little twist. Many teams use an internal clone of GitHub, Many others use Perforce. This doesn’t seem so bad at first, however, with each side of version control comes its own integration of code review, submittal processes, and checkin/checkout procedures. There have been several occasions where I needed to grab code from another team that was in GitHub and attempt to sync it with my code that is stored in Perforce. It’s a logistical nightmare.

It doesn’t stop there, though. Each method of version control has its own story. I won’t go too far in depth, but let’s just say that the goal of the company was once something along the lines of “We need to push code that works“. Now, the company is leaning more towards a philosophy of “We need to push code that works and is efficient, modular, and understandable“. This makes fixing bugs on older products or adding features to older products a logistical nightmare.

A Resolution?

One of the problems that I have found with Perforce is that its local repository management is more than complicated. There have been several times where I quickly want to branch a directory full of code so that I can play around with a  possible new feature, but be able to quickly switch back to the main devline of code. With Perforce, this is much more complicated than a simple git checkout -b feature.

So, in order to solve this problem, I have resorted to keeping all of my copies of the company’s source code within my own local git repositories. I then sync all of the Perforce checkouts into a branch and then merge that branch into all of my feature branches, resolving all conflicts along the way.

The Message

Although this post seems to have gone nowhere at all and made no constructive points whatsoever (that was definitely not the purpose of the post), it did point out something that I never expected. The internal infrastructure of large companies can be a serious mess. This being my first position at a large software development company, I honestly did not expect things to be as messy as my code directory on my home computer. But it’s also much, much worse. I believe that the problem arose from the fact that the company simply expanded very, very fast and that the internal tech employees were unable to adapt to newer tools quickly enough.

What does this mean? It means that now developers are stuck at a crossroads of bad naming conventions and commented-out blocks of code. They’re forced to use project-specific version control and they’re constantly deciding on which of the hundreds of branches they should push their code to.

Honestly, in situations like this, I think it is best for the company to stop working on new features for a small while, and fix their current infrastructure disaster.