A Guide to selecting the most appropriate web language for your organization
Part 1
What language should our company use to develop in-house applications? A question that appears to carry with it a simple answer but too often, the decision isn’t well thought out or doesn’t originate from what makes sense for the organization as a whole. It’s important to approach the decision from multiple points of view and to factor in more than just technology; team perspective is just as relevant.
This two part series was developed with Information Technology Management in mind with the hopes of stimulating a different way of thinking about language choice in an IT shop. Part I focuses of the process of selection. Part II breaks down a real-world scenario where an organization uses its team members’ current skill set to transition from a fragmented but mostly Java shop to a Groovy on Grails shop. While no one language is the right answer for all teams, Part II demonstrates an example of applying the principles discussed in Part I.
Introduction
The world of Information Technology is on a constant path of change and nearly all of it is out of the hands of any one organization. Organizations can opt to change with it, and continue to provide its customers with the data and information they demand or to not change and watch slowly as fewer and fewer customers turn to them for timely, relevant, accessible results.
Adopting to change is not just about maintaining a customer base. It’s also about being able to provide services that may be mandated by governing authorities, reducing the costs of processing requests, increasing the integrity input/output, providing expected or required levels of data protection, and controlling the cost to manage local IT services. A significant part of that cost is producing those services by building out in-house applications.
Once the decision has been made to develop custom in-house applications and a technology stack has been identified, the next step is to determine the most appropriate programming language for the organization or unit. Language selection should be driven by several factors and chief among them is the selection of frameworks.
Frameworks
Frameworks allow programmers to use a consistent pattern to receive, process, and produce data. They take the “busy work” out of app dev by handling events and processing parts of the request that need to be dealt with but are not directly part of the business problem.
For example, a framework should provide a way to secure a web application from unauthorized access into the system. It should allow a programmer to describe what “secure” means and what to do when a secured resource is requested. Spring security is an example of a web security framework that can be plugged into just about any Java application framework out there. Assigning a staff programmer to write the organization’s security framework is not only a waste of time; it’s also a risky idea.
A lot of smart people write and maintain frameworks and the community at large validates their usefulness by using them or not using them. Over the last twenty years or so frameworks have come and gone but several have stood the test of time and evolved into what has become a de facto requirement for building web applications.
Technological Costs
Generally, languages are free but their dependencies are not always free. For example, Adobe ColdFusion is cost $1,500 for a standard license and $8,500 for an enterprise license. However, it’s a full package solution. It ships with a pre-configured Tomcat application server and several admin tools, it runs on most major platforms, and is supported by Adobe. On the other hand Java is free. Tomcat, the most popular servlet container is free. GlassFish, the most popular application is free. Eclipse, the most popular development platform is free. Java’s runtime JRE (JVM) is free. And finally, if running the app on some Linux distributions, the platform is also free.
Other costs include the tools necessary (or highly recommended) to write applications and to distribute application. Microsoft Visual Studio is needed to write C# and .NET applications. Distributing an iOS mobile app requires a yearly developer subscription to Apple, yet Android is completely free. One should be sure paying for a language solution is a necessary cost and in the best interest of the service that the organization will be providing. Sometimes the cost is necessary but it should be backed with quantifiable conclusions and not just antidotal observations from strong minded individuals.
Delivery Of Applications
Desktop applications, web applications, network application, and mobile applications are very different and while they can all be written – to some degree – with most languages, language unification around all delivery mechanisms is a bad idea and any attempt to do so, would almost certainly manifest expensive problems shortly thereafter.
ColdFusion, for example is a relatively fast language to pick up but it’s a web application language designed exclusively for running small to medium sized web apps that use a traditional request/response paradigm. On the other hand, Java and .NET are both well suited for desktop, web, mobile, network, and just about any other use case. However, they are not as quickly learned and mastered and require external libraries/dependencies to accomplish all of the above.
Some languages are said to run on any platform. The quintessential example of this is Java, though a bit misleading. Java runs on any platform for which a JVM (Java Virtual Machine) exists. Since Java runs on a JVM and code must be further translated to the machine code it runs on, Java was viewed for many years as slow. This too is misleading since speed issues have long been resolved and are considered nearly inconsequential in today’s applications. However, for high performance network computing, C is a much better choice since it runs natively on the machine itself without any VM. Another example is .NET. .NET applications require a Windows environment so if an organization’s infrastructure is mostly non-Windows, .NET is not a recommended choice.
It’s a good idea to choose a language that can be used for the majority of application types and one that can be run with the least amount of effort on most or all platforms.
Standards Based
The Web has been around for a little more than twenty years and web applications have been around almost as long. To say web applications have evolved in that amount of time is an understatement. Not only has the HTTP protocol changed significantly in that time, so too has the demand and expectations consumers have placed on web applications.
As more and more expectations were placed on the application, applications grew larger and more complex. Programmers trained (or not trained) in application development found themselves having to write scalable containers and complicated data pathways through their applications just to solve an otherwise simple business problem. Many were ill-equipped to write such applications and consequently some web apps lacked scalability and suffered from poor usability, buggy code, security holes.
As the software engineering community struggled to find the most effective techniques of working with this new challenge (web vs desktop) a set of standards and best practices emerged. Today, these well-tested solutions to common problems are implemented and shared with the community at large in the form of patterns, frameworks, and libraries.
Standards are critical to the success of an application, not only in producing the application, but also for the lifetime maintenance of the application. Today, developers are formally trained or otherwise learn the standard proven approaches to problem solving. Employing standards simplifies handing off a design from one developer to another and increases the predictability of the code. They also make debugging straightforward and reduce the likelihood of over engineering a solution and introducing a maintenance nightmare.
Industry And Developer Proliferation Of The Language Of The Language And Its Frameworks
Perhaps the second biggest factor to consider when selecting a language is popularity. Honestly answering a few questions should weigh heavily on a language selection discussion.
How many [web|mobile|desktop|etc.] applications use this language?
The Java community likes to boast that over 3 billion devices run Java and they have good reason to. For better or for worse, it suggests that the language is pretty popular is likely to stick around for a while. Even if industry leaders – over night – were to tell the word Java is on its way out, the need for Java developers would not be impacted for a long time to come. After all, 3 billion devices and billions more applications would need to be maintained for at least some time. In reality, there is plenty of room for multiple languages at the forefront of industry.
How many developers in the region or your pool know this language? How long to bring a new developer up to speed?
A very important factor is availability of programmer resources. If migrating from one language to another, how many exiting team members know the new language? If hiring new developers, how prevalent are they in the community? If planning to train developers, how heavy of a lift is the new language to learn?
A programmer trained in functional programming may struggle with adjusting to an object oriented language or the MVC style of programming. Node.js is a JavaScript platform and JavaScript is a typeless language that relies heavily on closures. Closures not easily grasped by some programmers. On the other hand Groovy is so close to Java that the learning curve for a Java programmer to learn Groovy is nearly flat and not very long.
How mature is the language? Is the adoption rate increasing or decreasing?
In the last dozen years, several popular web languages have popped up and have taken hold in certain segments of the community. Some examples include but are in no way limited to: Scala as a replacement for Java in the early 2000s that runs on the JVM, Rails (framework) in the mid 2000s as a convention over configuration web frameworks that runs on Ruby but with out the popular criticisms of Java, Grails (framework) shortly after Rails as a Groovy version with all the benefits of Rails but able to run on the JVM, Node.js in the late 2000s as JavaScript platform for building server side web apps in JavaScript.
As new languages and frameworks emerge, some languages struggle to keep up and begin to fade. For example, ColdFusion was a wildly popular for many years and to this day is still being actively used and maintained. However, its popularity is fading. It began as a procedural style language but to survive, it needed to adapt to add support for object oriented programming. By design, it never fully achieved that goal. When the RESTful style of web programming blew up in popularity as an important technique to decouple the front and back-ends, ColdFusion fell even further behind. When it finally added the RESTful feature, it was and continues to be plagued by bugs.
Programmers gravitate toward languages and frameworks that offer out-of-the-box solutions to the everyday problems they’re faced with so they don’t get in the way when solving the business problems they’re hired to solve.
This cannot be understated when looking to hire talented programmers with the intent to keep them around.
Who owns the language? Is it being actively maintained? Are there add-on/plugins/libraries available? How many go-to frameworks exist for this language? How actively maintained is the framework?
This series of questions is to help answer the more general question: if the language can’t do it natively, is there a public distribution structure in place to use libraries that can do it? Many language-communities provide this feature. Java and Groovy have the Maven repositories, Node.js has the NPM repository, PERL has CPAN, Ruby has gems, Python has PyPi, and front-end JavaScript developers have Bower.
Without public support for sharing libraries and a mechanism for peer-reviewed / peer-tested code, programmers are left to reinvent the wheel time and time again. Valuable development time is wasted on developing common code. Programming is very much an art and like other artists, programmers enjoy sharing their creations with the community. Look for programming-communities where there is a groundswell of support for sharing their craft.
Committing To A Language And Framework
There are plenty of benefits to committing to a singe language or framework in an organization. Among the staff there is a consistent and predictable knowledge base. The ease of sharing or transitioning programmers from team to team is valuable for a project manager and management of a single infrastructure to support app distribution is valuable to a system administrator.
Language unification is not without its pitfalls either. It can lead to a lack of skill diversity among the organization’s programmers. It may also force a technology on a problem that may be better solved with a different language and without careful attention, it will impede of the intellectual growth of an organization’s programmers by reducing their professional exposure to other languages.
Weighing the pros and cons of selecting a common language should also take into account the purpose of the organization. A consulting firm is better served with a diverse body of languages and frameworks whereas a government agency is better served with a unified approach to app dev.