CWYOL: The Future of Software Engineering

Current trends in the software development industry, such as DevOps and microservices architecture, emphasize the need for more agility to deliver software faster without compromising quality. One of the approaches used to achieve this goal is giving software developers the ability to decide the technology used, in general, and the programming language in particular for building their components and services, which I like to refer to as the Come With Your Own Language (CWYOL) trend.

The One-Technology-Stack (OTS) approach has been the dominant model, especially in software development houses, I think mainly because of the investment put toward learning that technology to exploit its full features, and also the risk of mixing different technologies in the same system and causing maintainability, support, and resource issues on the long run.

However, all that has changed now. With containerization and microservices architecture, a software engineer can develop applications with his/her favorite programming language, expose its functionality as REST web services, and then integrate it with other services, which could be developed in different technologies and/or different systems.

CWYOL has become the preferred approach with the largest tech companies. For example, when looking into software engineering positions offered by big tech companies like Microsoft, Google, or Amazon, you can see that the required skills include knowledge and experience in one of the modern programming languages, such as Java, C/C++, Python, or JavaScript.

I think that for any language to be considered one of these modern languages, it should support:

1. HTTP for REST sync model between microservices, the core requirement for microservices architecture.

2. Reactive Programming for the event-driven async model between microservices and other resources. I believe this will be an essential requirement in the near future, due to the enormous increase of internet edge devices (IoT) and real-time data analysis (Big Data), which demand a new level of scalability.

3. Explicit Declarative Dependencies Management: Based on the 12-Factor App recommendations, which is the de-facto standard recommendations for designing modern cloud-native applications, having an explicit declarative dependency and using dependency management software, like Maven or Gradle, is significant for any modern applications. In fact, this will be critical to enable application containerization.

The CWYOL approach has benefits such as enabling agility and more creativity due to giving more power to software engineers, standardization, architecture, and code quality may be the primary concerns. However, standard coding convention, exception handling, and API documentation standardization could be hard to achieve since they may contradict the with technology-specific recommendations such as Java coding conventions and JavaDoc.

For more information about microservices architecture, refer to my article "Monolithics and Microservices: Software Architecture in Real-Life Applications."