The Path Less Glamorized

I see lots of junior software engineers looking to work in spaces outside traditional application development. LinkedIn is filled with posts about what juniors can do to get into blockchain, AI, and machine learning spaces, but I don’t see many articles being posted about traditional application development.

With that in mind, in this article I’ll cover a type of traditional application development: enterprise software. There’s a massive market for software engineers, juniors included, to begin working in this space, despite all the news about AI replacing software engineers (which I have yet to actually see happen in my own experience). It might not seem glamorous on the surface, but it has depth, high-paying salaries, and long-term career growth; and, it’s relatively easy to break into and less competitive compared to some of the sectors I mentioned above.

Let’s dive in.

What is Enterprise Software

When we refer to “enterprise software,” we mean software designed for use within a large organization. There are two main perspectives from a software engineering viewpoint:

1. Internally Developed Software: This type of enterprise software is built in-house for a large company to support its daily operations. For example, an insurance agency might develop its own Business Intelligence (BI) analytics software to analyze customer data and optimize insurance plans. These custom solutions are tailored specifically to meet the unique needs of the enterprise.

2. Commercial Enterprise Software: This is software developed by a software company and sold to other businesses of all sizes. It addresses common business needs that internal tools or smaller ad hoc solutions cannot easily manage. For instance, Product Lifecycle Management (PLM) software helps companies streamline product development processes and workflows. Rather than developing and maintaining such a complex tool internally, companies often find it more cost-effective to purchase commercial PLM software.

So, enterprise software is usually either an internally developed software suite to meet organizational need; or, it’s commercially developed to sell to other companies to meet their common business needs.

While this explains what enterprise software is, it doesn’t show how its developed differently than non-enterprise software. When we think about it, what makes developing a PLM different than developing, say, a blog engine?

The short answer is that much of the development process is really the same. However, enterprise software is often part of a much larger system of software that specifically target business needs. Enterprise software also tends towards flexibility in this regard, allowing organizations to swap in and swap out parts of the system when business needs change.

There’s also perspective of the “ecosystem” in which enterprise software engineering thrives. Due to the complex nature of enterprise systems, some sprawling ecosystems of software tools, technologies, and programming languages have coalesced to form a sustainable environment for development, deployment, and maintenance of these applications. What we’ll talk about next are two of the major ecosystems you’ll find in enterprise software.

Java

There are typically two major ecosystems where enterprise software engineering lives and grows: Java and .NET.

Java EE (Java Enterprise Edition) is the core of the Java ecosystem. In the simplest terms, Java EE runs programs written in the Java programming language on a Java virtual machine (JVM). As long as a platform has an implementation of the JVM, then a Java program can be run on that platform, making it easy to target multiple platforms.

Some other common members of the ecosystem are:

• Spring Framework: A framework for developing web applications using a well-established collections of tools, such as Sprint Boot and Spring Data.

• Oracle Database: This RDBMS uses SQL and integrates directly with other Java EE tools.

• Maven and Gradle: These are two separate build tools that allow for control over build automation of Java applications.

• IntelliJ IDEA: This IDE is widely popular among both enterprise Java developers and non-enterprise ones.

A standard Java enterprise application might look something like this:

Frontend: JavaScript using React to build the UI.

Web API: Spring Boot using Java EE to build a robust web API.

Database: Oracle Database containing one or more databases with which the web API will interact.

.NET

The other major ecosystem is .NET. Living in the .NET ecosystem are a large set of tools mirroring those in the Java ecosystem, but with a few twists.

The core of the .NET ecosystem revolves around running C# code, compiled to an intermediate language (IL), on a virtual machine. Specifically, .NET’s Common Language Runtime (CLR) executes the IL that has been compiled from the C# source code.

Other members of the .NET ecosystem include:

• ASP.NET Core: A cross-platform, high-performance framework for building modern, cloud-based, internet-connected applications. It includes a robust set of tools for web development, especially in Blazor application development.

• Entity Framework (EF) Core: An ORM (Object-Relational Mapping) framework for .NET applications that simplifies data access by mapping .NET objects to database tables.

• Micosoft SQL Server: A relational database management system developed by Microsoft, which integrates seamlessly with .NET applications and supports SQL for database management.

• NuGet: The package manager for .NET, providing a central repository for .NET libraries and tools, facilitating easy integration and dependency management.

• Visual Studio 2022: A highly popular integrated development environment among both enterprise .NET developers and non-enterprise ones, offering comprehensive tools for development, debugging, and deployment.

A standard .NET enterprise web application will look something like this:

Frontend: TypeScript using React to build the UI.

Web API: The ASP.NET Core Web API project is what most modern teams are using.

Database: Microsoft SQL Server containing one or more SQL databases. There may also be some other programs built with MS SQL Server, like SSIS packages, for manipulating data on a scheduled basis.

Modern .NET Applications

Blazor is becoming increasingly popular in the .NET ecosystem for web development. It uses the .NET Razor syntax, traditionally for server-side rendering, and extends it to the client-side via WebAssembly or server-side with SignalR. This enables developers to build interactive web applications using C# instead of JavaScript.

The component-based architecture allows developers to build UIs using reusable components with C#, HTML, and CSS, promoting modularity and maintainability. By using C# for both client-side and server-side logic, Blazor enables full-stack development with a single language, simplifying the development process and reducing the need for context switching.

Applications can leverage the extensive .NET library ecosystem, incorporating features like dependency injection, LINQ, and async/await to boost productivity and code quality. Blazor WebAssembly runs client-side for near-native performance and offline capabilities, while Blazor Server runs server-side, updating the client UI over a SignalR connection, which is ideal for complex applications.

Legacy .NET Framework Applications

In the enterprise world, you’re bound to encounter so-called “legacy” applications. In the .NET ecosystem, these typically refer to software built on the much older .NET Framework. Such applications conform to older project architectures like WinForms, ASP.NET MVC, and WebForms.

A significant portion of these applications are written in VB.NET (a dialect of Visual Basic), rather than C#. This makes maintaining legacy applications particularly challenging for software engineers new to .NET for two reasons: firstly, the legacy project templates use architectural patterns that are quite different from modern .NET applications; secondly, VB.NET is not commonly used among contemporary software engineers.

Legacy applications often persist in enterprise software suites because they are expensive to replace. Another reason is that companies sometimes remain unaware that legacy applications are still in use within the organization. These applications continue to be used by a small subset of users who are content with the current state of the software, never reporting bugs or requesting new features.

Here’s an example from my own experience with legacy enterprise software. My team was creating a new feature in our payroll application, and test users reported they could not log in. The payroll software was a legacy WebForms application written in VB.NET and connected to backend services for functions like authentication. After sifting through what seemed like a book’s worth of error logs, we discovered that the payroll app was authenticating users with an old WCF service (Windows Communication Foundation) created nearly 20 years prior. The bug was in this service. However, there was no documentation on this service, and no one in the department knew anything about it. We ultimately decided to retire the service and connect the payroll application to our modern authentication system. This decision cost us significant development time, but it was our only choice due to the lack of documentation and familiarity with the old architecture.

Wrapping up

Enterprise software can be both developed for internal needs or developed to be commercially sold. There are long-standing and growing ecosystems in both Java and .NET to build enterprise software. Practically every business out there needs the assistance of some type of enterprise software in their day-to-day operations, so I strongly believe this is a space that will continue to grow for software engineers.

There’s also the interesting and somewhat mysterious part of enterprise ecosystems in “legacy” software applications. If you like the idea of exploring older code bases or even attempting to port a legacy application into a modern language and framework, then there is plenty of opportunity here.

One thing I didn’t mention is that Java and .NET are not the only enterprise ecosystems out there. These are just the two I personally know the most about and have observed most frequently. There are tons of other ecosystems out there that are just as good for building enterprise software and can offer an exciting change from Java and .NET. I’d be doing everyone an incredible disservice if I left them thinking Java and .NET are the only path to follow. Some active and fun ones that come to mind immediately revolve around languages like Python, Ruby, PHP, and Go. Check them out and see what’s out there!

If you or anyone you know wants to share their experience applying for jobs in the current job market, inside or outside software engineering, we encourage you to respond in an email to this newsletter! You may be featured in our next article.

Thank you for reading and we will see you in our next article as we continue our voyage.

Code on,
Matt Ryckman, Editor and Software Engineer