Our site is called “DevOps on Windows”, so you’re probably a Microsoft shop. If so, it makes sense to stick with tools, programming languages, and frameworks that are designed for the Windows platform. Use C# instead of Java. Use ASP.NET MVC instead of Ruby on Rails. Use MSBuild instead of Ant. Use SQL Server instead of MySQL. Write Windows services. Use the Windows task scheduler. Gain a deep knowledge of what your platform can do for you and use those features to your advantage. Resist the urge to allow a hot-shot developer to write code in his “language of choice”, because adding a new platform, language, or tool to your ecosystem adds a new recurring cost to your team.
I once inherited a Ruby-based rakefile build system that a consultant wrote for our Microsoft shop. This system required Ruby and several gems to be installed on any machine that needed to run the production build system. I replaced it with an MSBuild-based system that any machine on our network could run, because MSBuild comes standard with the .NET framework.
A developer in a Microsoft shop should understand that even though he likes Python and could be more efficient in Python (in the short run), writing that new application in Python will cause endless headaches for operations, who will now have to support an entirely different platform on every machine that needs to run that application. A developer that chooses to use a non-standard platform also does a disservice to other developers (current and future), who will now have to maintain that software in an unfamiliar language without the aid of shared libraries and coding patterns.
In addition to sticking with the technologies that are native to your platform, your team should also strive to follow the conventions established for that platform. In a Windows environment, there is no excuse for installing your applications anywhere but the Program Files directory. It is not 1993 anymore – it is simply unprofessional to install your applications to C:\Initech. If your application needs to write out data files, write them to the %APPDATA% directory. Microsoft makes it easy to access these conventional locations via environment variables and, in .NET, the Environment.GetFolderPath method. Conventions and standards are powerful because they reduce the learning curve for everyone involved – developers, operators, and users alike.
As a final note, the point here is not to advocate Microsoft over other technologies. If you’re a Linux shop that’s committed to Java, I would not suggest you start using C# or ASP.NET. The important thing is not which platform you choose, but that you stick with that platform once you’ve chosen it. Limiting the number of technologies you use is an important part of the DevOps process of keeping your software systems easy to maintain.
