Java Development Team VS “Trendy Technologies” In Legacy Projects

by QArea Team on Jul 20, 2017

Is your Java development team outdated after supporting a legacy product for several years in the world of constantly evolving technologies?

We must understand what is legacy code first to thoroughly answer the question.

According to Wikipedia, legacy code is source code that relates to a no-longer supported or manufactured operating system or other computer technology. This definition is not as clear as one may hope for it to be.

In reality, these “relations” or, in other words, dependencies often lead to corruption, failed features, buggy releases, and poor time-to-market delivery. Or, if put more simply, operations in a product that has legacy code in it will take more time than they should.

That noted, above mentioned events are frequent guests in legacy software projects, but “frequent” is not the same as “always”, meaning we are still left without a clear definition.

This is exactly why our engineers prepared our own, custom definition for legacy code.

According to QArea, legacy code is a task that requires additional analysis. Only after careful inspection it can be evaluated and considered as either pain or gain.

Not more, nor less.

So it’s Java VS what now?

Let’s say you have a product with legacy code. And, at the same time, you are on your toes with new technologies. This will lead to a paradox where you want new tech implemented in your product for it to enhance delivery speed, patch and fix new issues and whatnot.

Sounds fine and dandy, does it not?

In reality, you will be slowed down by countless errors on integration and implementation stages. What, can you do in this situation?

Frankly, your options are not as rich as you’d like them to be. We’ve analyzed 80 projects with legacy code we either re-developed or maintained over the last few years and here’s one of our findings:

“In 10 cases out of 10 new technologies are not compatible with older ones from the box. Refactoring legacy code is required for them to play along nicely.”

In simpler words, integration of newer technologies takes more time and effort than maintenance of older ones.

Is working with legacy code a better choice then?

The choice of whether new technologies will be a better fit for the product can not be based on new technologies themselves, despite whatever they are capable of. This choice has to be based on the product’s initial architecture. If it was initially designed to be scalable you – in theory – won’t ever need newer tech.

You still might like the looks and feels of newer frameworks and programming languages, but your project will never be desperate for them.

There’s that and there’s the fact that, liking something is not a solid background for an ongoing business decision.

The best way of knowing if your Java development team should stick with the solution the way it is now is through a total architecture review. Here’s what you should look at:

Stability
Scalability
Performance

Working with legacy code will be a breeze, if it was initially designed correctly and can withstand massive load and pressure today. Adapting new features in scalable products that have used something resembling micro service architecture is merely putting more blocks on a Lego tower.

Sadly, this is the rare case scenario.

What usually happens for older projects is the fact that business owners are simply hostages of their previous architecture choices.

Java experts from QArea have noticed a pattern – legacy code is usually neither stable or scalable. What we do here is we perform a detailed review, analyze and structure data to show which areas of the product are flawed and how one may fix them.

The impact of the review always hits like a truck. It’s just plain painful to realize that a project you have already poured a small fortune in is useless and needs total rework and as much, if not more investments.

Consider this as a chance to learn from previous mistakes.

Stick to Java?

If, and only if the product does not meet expected standards of scalability and/or performance, the time has come to replace legacy code. From here, we have two ways of development – we can use Java or switch to a different technology entirely, given the fact that the entire architecture will be redesigned.

This choice is up to you and your business goals, but we would still suggest to stick with Java. It will be simpler and cheaper in the long run and the language, if used right, is still fairly scalable.

The guys from Oracle release new versions with updates and patches every year or two with no intention of stopping. That’s one hell of an advantage of the Java language.

This can potentially bring in some maintenance pains later on (despite the claims of 100% compatibility in integration) but the same can be said about any programming language. All of them have updates. Few are updated as frequently. Few will remain up-to-date in several years.

This is one of the core reasons to why is Java so popular on large-scale projects today.

Choose clusters!

After your decisions are set in stone, regardless of the language or technology you choose to make the product with, an appropriate architecture choice is pivotal.

Here, at QArea, we suggest Modular Architecture as it brings series of crucial benefits. With this model, each element of functionality is treated as a separate cluster and all the changes done within it will not affect the overall system.

We used this approach while developing TimeGuard, our internal project management platform that allows transparent, data-driven team performance analysis for both our managers and clients.

Cluster-sized features deliver one more benefit – you can develop your project with several vendors at once. Our clients usually practice the 80/20 model, when one team is developing core functionality and the other supports it with additional features.

This way vendor lock-in is easily prevented as you have several crews of talented engineers already knowing all there is to the product. Each of them can quickly jump on 100% of development if the need rises because one vendor failed or chose to raise prices or whatever other reason.

Preventive thinking

You can hire Java developers and give him the best Architecture the world has ever seen to work with and you will still face legacy code issues later on, unless development was tailored perfectly to leading industry standards.

Preventive thinking allows to fix the issue before it even emerges.

We, for once, use the best practices of the Continuous Integration methodology that not only allows us to prevent mistakes but can also fix existing legacy code issues (if they are minimal) without re-developing the product from scratch.

Our CI processes stand on three whales: Continuous Integration, Inspection, and Feedback.

Integration

CI is considered a rather investment-hungry methodology as it demands absolute dedication, but the ROI from it skyrockets in the long run. You basically get a bigger bang for your buck.

Why? Because fixing defects on earlier stages is cheaper than letting them slip into the product to be spotted later on by the QA department.

Continuous integration is based on 100% unit test code coverage and the lion’s share of defects is spotted before they are submitted to the product. We also compliment Unit Tests with a custom SQUALE based product that automatically checks all code inputs. It works like Sonar with slight adjustments – our product actually teaches developers and gathers analyzed data on a live board for you to review.

The process usually runs as follows:

Often (at least 1 time per day) code is being “filled” into the repository;
Automated tests are being written;
Private builds are run (the assembly process, which is performed with the use of the source code that is currently located in a local Developer repository);
Broken code is not “filled in”;
Broken builds are fixed forthwith;
All checks and tests are ensured as made and none pumped out of the broken code repository.

Inspection

From the business perspective, knowing about all potential risks is a victory on its own. Based on the risks you can plan ahead releases without fearing drawbacks.

We choose to visualize every development process to stakeholders through TimeGuard in a handy interface of a live board.

Our data-driven analysis does not only allow you to play the blame game by learning who performs better in a team.

It does not only allow us to educate Junior developers on practical cases.

Continuous Inspection allows for you to plan ahead quickly, while completely realizing the bigger picture.

Feedback

The process of building a feedback process in a convenient matter is one of the most crucial elements of software development. In order to plan ahead you not only need the data, but you need it to be delivered to you.

A live board is always nice and dandy, but we still choose to fuse it with traditional channels like browser plugins, phone, Skype, Slack, and email.

This is how you prevent technical debt from ever gathering in your project and avoid legacy issues on an ongoing basis.

Do you still have any questions left? Contact us! We will be glad to explain the process in more detail!

Check out our related articles:

10 Java Experts And Developers To Follow On Social Media

Java Software Development Technology

5 main features of Java 9 to create top-class projects

We Help With

Your tech partner needs to be well versed in all kinds of software-related services. As the software development process involves different stages and cycles, the most natural solution is to have them all performed by the same team of experts. That’s exactly what our diverse range of services is for.

The choice of technology for your software project is one of the defining factors of its success. Here at QArea, we have hands-on experience with dozens of popular front-end, back-end, and mobile technologies for creating robust software solutions.

In-depth familiarity and practical experience with key technologies are one of the cornerstones of successful software development and QA. But it also takes specific knowledge of the industry to develop a solution that meets the expectations of the stakeholders and propels its owner to success.

Services

Technologies

Industries