::DRAFT::

We’ve all had to work with legacy systems at some point in our lives, and we’ve all felt the burning desire to rewrite such systems to make some aspects of our lives easier. And you’ve probably learned very quickly that modernizing applications within the constraints inherent in the big enterprise is not for the faint of heart.

In my previous role, I was responsible for formulating an effective application modernization strategy in an organization that had significant legacy technology investment. For the most part, I failed to achieve what I set out to accomplish, and I have often reflected on what I could have done differently, and what actually worked in my approach.

Before I dive into my opinions about approach, lessons learned, or choke points encountered in my adventures, I feel that it’s worthwhile to settle on some terms and definitions.

Legacy Systems

Any application which is considered at-risk for a variety of reasons. In a world where outsourcing is commonplace, whether that’s using offshore or onshore partners, businesses typically do not understand the systems that they are paying to have built. Part of this will be addressed in my section on Methodology later in this writeup.

The following anecdote helps to properly set the stage for my definition of legacy.

Existing applications that are poorly understood are expensive to change partially because they are expensive to analyze. Business analysts do their best to create design documents based on their analysis of the app, and the changes that are driving any sort of development effort for a given application. However, in this big design up front (BDUF) approach, things are missed, time lapses, requirements change, and the business customer gets antsy because they are putting forward significant investment and not seeing any returns.

At some point, the development team gets to start working with the code. The perception is that they are now under the gun to produce the work as quickly and as cheaply as possible because the project is already falling behind. Problems ensue due to lack of documentation, code quality, consistency, or lack of automation. The business stakeholders becomes further frustrated, as more money seems to be flying out the window, and as timelines, target dates, and budgets all seem out of control.

After months of this song and dance, the legacy system gets shipped, and then the bugfix period commences. More frustration, more money is perceived as lost forever to this “black hole” of an application.

Eventually, another group of developers comes along and proposes that they can rewrite the app, promising that they can help the business avoid these types of problems in the future. The business responds with a resounding “no”, citing risk, budget, and previous development teams apparent failures as reasons why we should not dare to touch their hard-earned, working software system.

---

The first question that I ask myself about that opening anecdote is “why?” Why was the system so hard to analyze? Why were requirements missed? Why did the development team have such a hard time going through their changes? Why did quality suffer?

One of the good things that comes out of any business analysts work is the historical background of a given application. In many cases, legacy systems were developed by someone who is no longer with the company, or maybe even someone who is still with the company but doesn’t have the time to (or just doesn’t want to) provide any sort of help.

Maybe the system was developed completely offshore using a waterfall methodology. Maybe the system was developed by someone on the business side of the organization, having taken a few night classes on programming to try to automate some mundane part of their corporate day job. Maybe the team that even developed the software to begin with no longer owns the system, and are assigned to something else and again, can’t or won’t help the new team with their work.

All of those scenarios are commonplace with existing software. But, aren’t all software developers professional, don’t we all use the same standards and patterns to help ease the development team of tomorrow easily understand what the development team of today laid down as code?

The simple answer is no.

Some of this has to do with the fact that software development, whether it’s the languages, the frameworks, the tooling, or best practices, all seem to be changing around us at the speed of light. Learning something new may be harder for some and easier for others, but regardless it takes time and work.

Another aspect to this same problem is the means by which developers are trained. By all means, a computer science degree is a great thing to pursue for those who are hoping to work as a professional software developer. However, not all colleges and universities produce good software developers. Most developers then have to learn how to build systems on the job, and most give up or are placed outside of dev orgs after only a few years. This results in code that was written by completely new developers who never learned or were never properly guided into writing good code.

Businesses and IT departments try to mitigate this risk by settling on one set of languages, components, etc, in order to minimize the sound to noise ratio for developers and to minimize the amount of special snowflakes that are produced by developers. They also try to mitigate this risk by shackling more experienced developers with less experienced ones, hoping that coaching or mentoring developers will help to produce better code. However, this has the adverse effect of preventing development teams from picking up on newer, more effective practices or tools. Experienced developers can’t focus on continuing to master their craft, and less experienced developers only learn what’s already known.

Let’s also take a moment to acknowledge that building a new software system, or even making changes to an existing one, is not a factory type process like so many IT organizations seem to believe. A factory process assumes that you’re building one thing and doing it en masse. It’s easy to forget about the amount of R&D that went into getting to that point. Software development is actually the R&D part that gets you to the point of having a working product to be used by the masses.

It’s a pickle.

This results in a checkmate between business teams and development teams. Businesses want working code, and they typically want it either on time or on budget. Development teams want the same, and do the best they can to do both what they love and what they get paid to do.

At this point, hopefully, it’s becoming apparent why it’s hard for us to do what we do, and why the perception about software development teams in the enterprise are so low.

---

Ok, so what can we do about it?

Many of you may have already recognized this problem, and many of you are probably thinking that I haven’t included some seemingly obvious dysfunctional aspect that is prevalent in most present day corporations. I believe that what’s been excluded here can still be answered using one or many of these approaches.

I won’t pretend to claim that I have a silver bullet, one-size-fits-all answer for everyone in every situation. I’ll also warn that this will be slow, painful, and will require multiple iterations to get right. As a company, you will have to be willing to allow for all of those things, otherwise you’ll never make progress and modernization will remain a pipe dream.

---

 

R&D as a means to drive change

 

---

Ninja Groups

These groups exist in every organization whether it is openly acknowledged and embraced or not. These teams are often the most successful in doing things in a new way, but because of how they came to be, they are often the least effective model to apply to the rest of the organization.

---

Outsourcing

Large enterprises have been outsourcing some percentage of their software development and operational needs for years. It would be a mistake to think that we could simply cut this aspect of the enterprise out of the equation. Instead, serious thought needs to be given to how modernization sits alongside these partners.

---

Risk Adverse Organizations

These types of organizations do not want to make change based solely on the notion that they do not want to take on perceived risks. These types of organizations can be the most painful to deal with, since they are staunch in their beliefs.

---

Siloed Organizations

Many large organizations have created silos with the best of intentions. However, these barriers often inhibit change. It takes time and patience to navigate through these barriers, especially in organizations that have become accustomed to “building their own kingdoms.”

---

Methodology

Agile. I’m sorry, but I won’t budge on this one. As was previously stated, software development is actually R&D. In the software world, this is an iterative process. A software project is never actually completed, even if there are long pauses in active development. There’s always some feature, some bug, or some business strategy that will cause us to crack open the code and begin R&D anew.

This is not an effort to sell you on the merits of agile, nor an intro to agile. The web is full of articles that cover those topics. I am simply stating the importance of this methodology as it pertains to the success or failure of modernization efforts.

Agile isn’t just a project management methodology, or a backlog, or a planning and forecasting tool. Agile is a set of software development practices that are designed to build and ship quality software in an iterative manner.

---

Required Skills

You don’t have to be the greatest developer, but you need to be empowered to learn, and supported in your failures. Failure leads to success. Organizations need to understand this, especially the risk adverse ones. This should be good news, because it means that you don’t have to compete with silicon valley tech companies to bring in talent to write  or modernize your software.

---

Tools

If you aren’t willing to pay for the right tools, or to allow your teams to build up the skills necessary to support free versions of such tools, then you’re not going to be successful. Many organizations will not have the funding necessary to buy the great tools, and those that don’t need to be open and supportive to their teams in overseeing freely available tooling. The point here is not to focus on the skill conversation, as above, but to point out some tools that are absolutely required to run modern software systems.