Loading...

Migration: Developers and persistence

07-Sep / 0 COMMENTS

 

Story of fellow developer who survived it more than once

 

When you work with mainstream technologies, such as Java or .NET, biggest fight you’re taking is to find developers with good engineering and soft skills. On the other hand, when you deal with unpopular stack, major challenge is to find developers who are motivated to develop themselves inside that scope.
In my professional career, I had an opportunity to work with many different languages and frameworks, on many different platforms. During that time, I had way more problems caused by how they have been used rather than with a quality of technology itself.

 

Application, we inherited, was developed in Adobe ColdFusion and IBM RPG.
As any other software, the sole purpose of this one was to support the business.  When business start growing, software needs to change accordingly. Requests start piling up: Better UI responsiveness, support for mobile applications, massive batch processing, and when you add exponential growth of users, we hit the limitations of current technology stack. That was the point where we decided it is time for change.

 

Rule
Business do not care for technology. They want things to work.

Challenge One

 

Migration is long running process that actually never ends.
Everything must be done in phases and tested thoroughly. No big bites.
Therefore, new technologies had to be able to adapt through phases of migrations process and proven in practice.

Since the most business sensitive part lies in database, we decided to leave it “as is”.
Not that there’s nothing to improve (opposite), but, as mentioned before, we had to take it slow.
On the other hand it gave us the luxury to make more radical cuts in application layer.
Old spaghetti will be divided in two parts: JavaScript front-end client and REST back-end.

Considering that ColdFusion was already running on top of JVM, Java EE emerged as the most logical choice. In process evaluation, most common aspects that people take in consideration are community (extensibility), performance (what includes library size, is it prone to memory leaks, etc.) and learning curve.

Depending of many factors priority may vary, but to us most important were learning curve, long term support and ability to adopt (extensibility). When it came to front-end, Backbone.JS won this race.

Working in large companies, with variety of different teams, brings you a benefit that you can almost always find someone who has previous experience with something you are interested for.
We strongly relied on that when we’ve been thinking about new (Java) application server.
Inside Enjoy.ing we already had 3 other teams who have been successfully running their projects on JBOSS AS (now WildFly). Without many hesitation we joined the legion.

Rule
Use the best tool for the job

Challenge Two

 

 

At the time we made a decision to start migration, we had solid team of five people with diversity of skills in all 3 layers. Problem was that none were particularly strong in any of technologies we should migrate to.
Buzzwords were there for good ad, but we could not wait until we find new team mates.
We had to start ASAP.

Domain knowledge is one of the biggest assets of a developer on the long running project.
Having such developers with a will to “listen and adopt” was our major strength.
We start learning: internal labs, workshops, trainings, online courses, blogs, we hit it from all sides.
It was just matter of weeks when we gain enough knowledge to start prototyping.

And didn’t past more than 3 months and we had first Backbone “module” backed by REST written in Java running in production. In the meantime, new colleagues arrived and rest is history.

 

Rule
Tool is not enough. Even more important is to know how to use it – WHO is using it.

 

 

 

Challenge Three

 

I won’t lie and start telling you fairy tales about testing. How we wrote numerous unit tests even before we wrote single line of code. We did not. Why? Because TDD requires a major shift in developer’s mindset and we hadn’t been prepared for it.  Not to mention that we already had too much to grasp. But, we’ve been aware that we couldn’t do anything without proper testing strategy. So, we decided to go with functional tests. In that regard, Selenium was our tool of choice. Each implementation step was preceded with a solid number of recorded tests.

As a rule of thumb, take that every task that need to be repeated more than 3 times should be automated and completed within a “reasonable”” time. Otherwise, it is only a matter of time when developer will gave up of it. Besides testing, deployment is one of such tasks.  To assist on this job we chose Jenkins CI. Automation is like an addiction. Once you get used to it, it will become integral part of all your tasks.

Rule
Automate and make it finish in reasonable time

 

 

Let’s wrap it up

 

And list can goes on and on. I could spend days writing about challenges we faced on our path of thorns and rules resulting from acquired experience. I didn’t even tackle the area of system administration, virtualization, configuration management systems (Puppet), etc.

But, at the end, it all boils down to people and persistence.
Developers are those who makes all these wonders possible.
Persistence is characteristic which is required to keep you going when you can’t see the light at the end of tunnel.

If you ask me, after all these years, was it all worth it, all I can is yes!
We learned so much, we grew in better professionals and persons as well.

Enjoy chang.ing!