In our newest edition of Featured Blog Friday, programmer Björn Vignir Magnússon delves into the decision-making process that the AGR Development Team made in choosing a programming language for backend development of AGR 5. If you have any questions or inquiries, feel free to comment below or tweet to Björn @BjornVignir.
One of the challenges in software development is to choose which technology stack to use. As a programmer, it is vital to learn new skills so your talent doesn’t rust in this continuous rain of new technology. In today’s rapidly changing world, skills expire like humid bread standing in the window sill. Before the internet, everything was different, every skill was learned from books, or passed on orally from generation to generation. Nowadays, development frameworks can be introduced to the world and become obsolete within a year, so it’s very important to bet on the right horse.
AGR 5’s development team recently undertook the arduous task of choosing a programming language for backend development. We had already committed on using AngularJS on the front end and have been happy with that decision ever since – AngularJS being a powerful toolset for making rich beautiful user experiences for enterprise solutions.
We decided to gather all the pro’s and con’s for Ruby, which we were already using, C# which was a likely successor and Node as a comparison. Node is the new kid on the block and has already had a tremendous influence on established frameworks like ASP.NET, introducing it to the concepts of modularity and cross platform development, for instance.
But what should we factor in our decision making process? Each of these programming languages has it’s own sets of pro’s and con’s and no matter which one we chose, we would have to work around the specific problems that came with choosing a certain technology.
The company’s main goal with AGR 5 is to make a scalable and repeatable solution that is simple to install and needs little or no maintenance.
Based on the company’s goals, we discovered several findings that had a say in our final decision. After deciding upon what was important to us as a development team and as a company, we came to the conclusion that moving the existing code from Ruby on Rails to C# in ASP.NET would be the best bet. Here are 5 deciding factors behind taking the leap (in no particular order).
5. Simple deployment
Our solution is deployed on our customers machines. When we are working on different kinds of servers, with different kinds of companies and different sets of security rules, things can get pretty complicated. That’s why it’s so important to simplify the AGR 5’s setup as much as possible. We already know our customers are using Microsoft IIS servers and deployment of an ASP.NET application to an IIS is pretty smooth. Ruby on Rails has to run on top of a program called HttpPlatformHandler which adds additional complexity to the installation process. The simpler the installation, the better for everyone involved.
4. Microsoft partnership
We already have a Microsoft partnership. When you are working with a set of Microsoft technologies, like SQL Server and IIS, you might as well use the whole stack and develop the code in C# with Visual Studio. Microsoft solutions play well together and using the development tools provided by Microsoft, that are designed to work together, we can save us a lot of time and pain finding third party components that might not do the job as well.
3. Active Directory login
It is just tedious to have to remember a lot of different user names and passwords. Passwords tend to get lost and then someone has to find them again. Also, the more user accounts you have, the lazier the passwords get. This is usually what happens when people have to create a new account, with a new password;
old password: “MyPrettyStrongPassword.123.4”
new password: “MyPrettyStrongPassword.123.45”
With ASP.NET we can use Active Directory login, so we can connect the Windows user to the AGR 5 login. You won’t have to remember your username and password for AGR 5, since Windows already knows that!
2. Inhouse knowledge
We did a quick survey in the development team, and found out that 80% of our team had good to expert knowledge in C#. It is important to use a development language that is well understood and maintainable within the talent of the company. It means that when we need to do changes or add features, most of the team is capable of immediately stepping in and getting things done.
1. Run managed code
Developing the backend solution in ASP.NET gives us the power of running externally compiled DLL’s, like the forecast modules we run to calculate forecasts for items, within the backend solution. ASP.NET also has well developed components for exporting data to Excel, for instance, which is a popular feature in our system.
(Bonus) Azure deployment
Cloud services are here to stay. Microsoft seems to be taking the initiative to push new customers into hosting ERP solutions in the cloud, as proven by their newest incarnation of Microsoft Dynamics AX, which will be cloud first. Developing our solution in ASP.NET makes it especially simple to deploy our solution, in development or production, to Azure. Since cloud services are the future, this really seems to be the way to go.
Bearing in mind our product’s goal and the findings listed above, the decision actually turned out to be pretty straightforward. No other development framework could handle the problems we need to solve and integrate better with our current development stack than ASP.NET’s C#. Moving from one development framework to another can be quite intimidating, so we took the approach of measuring twice, cutting once, which will assuredly result in an even better performing AGR 5.