Legacy companies

Software companies and companies with in-house bespoken software regularly struggle with nightmarish software systems: cryptic monoliths every development team fears and no one understands. Consecutive investments fail to destroy its legacy monsters and to prevent other systems to follow the same path.

Legacy state seems an unavoidable progression for software system, except for some “lucky” companies. The misconceived “luck” factor deflects attention from the real problem: legacy systems are created by companies – legacy companies.

Once upon a time

The first software products a company develops have great changes to become a tar pit of development. New companies have less resources, need to imposed themselves in the market rapidly.

Some “compromises” are made and developers accepted them gladly. Initial velocity sets productivity baseline for development teams to the outside. Anything below will be seen as not working hard enough.

The first products will become the business core, where most income originates from and where the development nightmare resides. Throwing those core systems away is out of the question. Financial needs don’t allow the company to slow down or risk major rewrites.

Becoming legacy

As soon as productivity starts dropping, pressure to deliver more will begin. It’s too late to push back, as developers have sold their souls. To regain reputation and trust, more concessions are made.

Continuing with “compromises” and errors will amplify the legacy base and slow down development teams productivity until senior management decide to take extreme measures. Then the problem will be on hands that know nothing about software development. Instead of seeing it as a sick body displaying its first symptoms, more business directed people will look for the part of the machine that got broken to quickly replace it.

Arguments as a project manager insecurity driving best developers away, CTO struggling to do a good job, feuds between managers or simply the whole company is a mess are discarded as excuses. The counter-arguments are people have been around for years, long before the problem appeared, so they cannot be part of the problem; if the problem is on software development, it is the software development teams fault.

No matter how many purges happen in the IT department and how many new people are brought in, the problem doesn’t go away, it only gets worst. Every single system seems doom to the same fate. Legacy state seems unavoidable or a matter of bad luck.

Those who stay behind

Developers early on deal with the frustration of working in such an incomprehensible dinosaur. Changing anything is too risky, the slightest error might have catastrophic consequences. Or they leave or conform to reality.

Legacy state prevents the system from migrating to newer technologies. After a few years everything becomes obsolete. Those who stay, risk obsolescence and feel threatened by new joiners with experience in more recent technologies. Their advantage? Knowing their way around the software maze and they will do what it takes to protect that advantage.

Is it that hard to change?

The pillars support the house and keeps it in its place. The company’s human pillars have been in the company for a long time, probably since the beginning. They proved their value. After so many years defining how the company works, convincing them they are doing things wrong and change is needed is no easy task.

Only problems reach epic proportions, it is demanded its resolution, quickly! Many princes step forward with some radical approach promising to slay the dragon in no time. A few years later, after the revolutionary technique is proven wrong, the prince leaves with no princess. Chaos from the battle is left behind.

There are no quick fixes or silver bullets. Change is slow and results take long to appear. The urgency to solve the situation is an enemy of the patience required. New people with different mindset have to be hired and placed in relevant positions. Feeling threatened, the pillars will be the first barrier of resistance to change and will be rooting for failure.

Conclusion

Legacy systems are cause by years of bad decisions, bad communication and bad organization, company wide. Problems are never technological or restricted to development teams. From developers to the CEO, everyone has impact on its outcome.

Many purges in IT departments happen to eliminate the symptoms from bad software development, but the root causes remain. Real change is required, but changing a company is harder than change a person: it is changing a lot of people, all at the same time.

Companies with problems in its Software Development are not doom, but are heading for a hard time. Software plays a important role in the company’s competitiveness and as a differentiator from its competitors. Lack of acknowledge and address internal problems will weaken the company and more legacy systems will continue to merge.

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s