Solving BIG Problems

Hello Friend,

I have been working with a new client.

They have a legacy application that was built in 2004.

If you have worked in the enterprise that might not be a big surprise.

You might even call it a “new” application.

Keep in mind in 2004 I was still in middle school.

I have been spoiled with the new world of continuous deployments and unit testing.

This week I have been digging into the source code.

Nothing but a headache after a headache.

The original developer had no developer experience.

You can tell by all the variable names, they are just strings put together.

x,y,z

i,j,k,l

I have to convert this vague code base into use cases.

Verify the use cases with the stake holders.

Convert this legacy code base from a legacy Java client side application to a more modern JavaScript Web version.

Not an easy task!

It’s going to take me months of coding to get through the entire project.

I’m going to have to go through meeting after meeting making sure that we leave no stone unturned.

And create something of value, that will last another 20 years.

This is a project that is going to require a massive amount of responsibility to build the right application.

The key to building something “right” is to build it with the future in mind.

Keep the code as flexible as possible and try to see far into what their business is going to look like in 20 years.

I know one thing.

Humans are horrible predictors of the future.

But I can tell you that tomorrow is going to look very much like today.

You can continue this thought and recurse over time.

My job here is to be able to understand as much as possible of what’s in front of me and move forward to the best of my ability.

That’s all I really can ask of myself.

Have you experienced anything similar?

A legacy application you had to work with?

Join the Facebook Group and continue the conversation.

Talk soon,

Rick H.