Definition

What it isn’t

According to Dictionary.com, Legacy, used as an adjective in the term Legacy Software, the definition is:

leg·​a·​cy | /le-gə-sē/  – of or relating to old or outdated computer hardware, software, or data that, while still functional, does not work well with up-to-date systems. 

The key to this definition is the “while” clause.  We know that old software doesn’t have to be called out as ‘legacy software.  As an example, what about Linux?  The Linux kernel is an old piece of software, but no one would classify that code as a piece of legacy software.  Why is that?  There are some key aspects of the software that have made it continually relevant over the years.  There is an argument that it is the most relevant it has ever been. 

Linux began in 1991 as a personal project by Finnish student Linus Torvalds: to create a new free operating system kernel. The resulting Linux kernel has been marked by constant growth throughout its history. Since the initial release of its source code in 1991, it has grown from a small number of C files under a license prohibiting commercial distribution to the 4.15 version in 2018 with more than 23.3 million lines of source code. (History of Linux) 

Why isn’t Linux an example of Legacy Software?  I believe we can identify some key things that lead to non-Legacy Software. 

• Strong leadership – Linus Torvalds has been involved from the beginning of the development effort and has implemented tools and processes that have established good software practices throughout the years, while still allowing other developers to contribute the software.

• Build Tools – Using traditional build tools the software build is automated so that anyone can download the software, build and deploy it on pretty much any off-the-shelf Intel compatible desktop.

• Well Tested – Through Linus’ strong leadership and his attention to delivery details, each release is fully tested.  The focus of this testing is automated testing, as might be expected from the size of the project, manual testing is not an option.  

• Relevant – The software is probably more relevant today than it was in 1991 because of the user involvement in the software.

• Documented – It is expected that as changes are made to the kernel they are fully documented, peer reviewed and the pull request accepted by Linus Torvalds.

• Good Developers – Because of its good leadership, testing and continued relevance, many developers are interested in continuing the development effort in order to improve the software.

• Culture – Linus and the Linux community have built a culture that creates complete, relevant and quality software releases.  

 These key attributes of the development history allow for a legacy of relevant software, not legacy software.

What is it

According to Re-Engineering Legacy Software by Chris Birchall, the definition of Legacy Software is:

” A software project that is difficult to maintain or extend. “
 – Re-Engineering Legacy Software by Chris Birchall

This definition is more straightforward and relevant than the previous one and it helps us understand why it is such an important topic.  Software is used by businesses to help them be more successful.  Most software helps companies become more efficient or effective, ultimately making them more productive and thus more profitable.  

An effectivity gain would allow a company to do more with the same, an efficiency gain would allow a company to do the same with less.  In either case, there is no magic, the software is automating what people are or could be doing, but doing it more consistently and/or at a larger scale.  Therefore, it is critical to understand that software should first be successful in providing this value to a company but also, and importantly, must be written in such a way that it can be maintained and changed so that this value can continually exist or even improve as the company changes. 

This is such an important aspect of understanding why legacy software is an important topic for information technology organizations.  With this in mind, there are some key aspects of legacy software that exist and can be identified:

• Old – the software, its language, and its libraries are old.  This by itself isn’t a problem, but as hardware, networking and other integration software is either added and/or changed, this can cause issues that must be addressed through library or other types upgrades.  As in the discussion of Linux above, the software and development staff has to put in the work to make this a non-issue.

• Large – Not all software is large, but oftentimes software that is important to a company and that is a legacy software concern, tends to be on a larger scale.

• Important – Along with large, if the software is a topic of legacy software within a company it is most likely important to the company and often crosses many parts of the organization or is a key aspect of the organization.

• Inherited – Legacy software is often inherited and not created by the current set of developers.  In the absence of documentation, automated testing and build tools changes can be brittle, not easily tested, ignored or avoided at all costs by the development group.

• • • Untested – Legacy software does not have automated tests.
    • No builds – Legacy software does not have automated builds.
    • Brittle – Legacy software is brittle so that a change in the software may lead to unexpected failures, many times in areas of the software not related to the change.
    • Technical debt – Technical debt is code that was baked into the software knowing it needed to be changed, but never was.
    • Fear – Because of all the prior attributes, developers tend to shy away from making any kind of change to the software that doesn’t need to be done.  So rather than hearing and understanding the user, the developer will only do the minimum to get done. 

The outcome of these attributes is a software product that becomes very difficult to hire and keep developers to maintain.  In tight labor markets, the lack of talent to maintain legacy software is one of the, if not the most important obstacle to maintaining and extending legacy software.

Options

Assuming legacy software exists within your organization, what are your options?  On the continuum of options that can be done to address legacy software, the two ends of the spectrum are:

1. Keep the software,
2. Rewrite the software. 

This may seem overly simplistic, but any option is somewhere on the continuum of these two options.  Oftentimes, keeping the software is the option only until it can be rewritten, or it may be that you completely rewrite a portion of the software.

Keep the Software 

How can keeping the software be a solution to Legacy Software?  Remembering that old doesn’t necessarily mean legacy, but rather the fact that it was not maintainable or extensible.  If we address the reasons software is not maintainable and extensible, then it stops being a legacy software product.

I am going to recommend the books, “Working Effectively with Legacy Code”, by Michael Feathers and “Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software”, by David Scott Bernstein which both provide key ideas on how to work with and extend legacy software.  However, rather than getting too detailed discussion, important straightforward steps must be taken to make these books useful to any of your efforts.

1. Create a build that implements the “Return Test”.  The return test is a term that I have used to describe a build and deployment process that requires a developer to type “build” and hit RETURN.  If this cannot be done, the software cannot be maintained or extended.  Software development is difficult but to also require the development to assume a fluid deployment, development becomes nearly impossible.

    

2. Create repeatable independent software tests that can be executed each time the software is changed.  This is a very important step to maintaining and extending legacy software.  This step may seem a little like building a car while driving it and it kind of is   since the software is actively changing.  However, one way to accomplish this is to implement the tests in the areas of the software that is currently changing.  As an example, let’s assume some work needs to be done with an Invoice, build in the time to create unit and integration tests for the Invoicing module, ensure the tests succeed with the current code and then make your changes and use the tests to confirm the module still works properly.

    

3. Identify seams in the software and then replace those areas that are appendages to the core software.  An easy example of this is a 3rd party integration or a user interface upgrade using a RESTful integration layer.  These can be replaced while not replacing core business or database layer logic.  

The following is a list of common work that is required for successfully maintaining and extending your legacy software within your company.

• • Automate the testing and builds
  • Make incremental changes with the end in mind and release 
  • Create good documentation into and out of a release cycle
  • Provide good leadership and talent
  • Extend with the user in mind
  • Fix technical debt as it is found

Rewrite the software

A rewrite of working software that provides value to a company is a major decision for any organization to make.  This type of decision usually involves company management and would include a budget outside of existing maintenance.  For this reason, a complete rewrite is rare.

However, many times a complete rewrite can be a long term objective so that the maintenance and extension of the software is done in such a way that over time the software is rewritten.  

A “complete rewrite” decision is most likely made when there are substantial changes that are needed to the existing software because of business requirements or technological realities.  

A new business opportunity is a great example of a business reason.  Another good example may be business growth or decline.  These business drivers many times create a need that just cannot be handled with the legacy software and to change the software would be too heavy of a lift.

The Windows 7 ‘end of life’ is an example of a technological reason.  We worked with a company that had a Windows 7 embedded system that had to be rewritten.  In addition to this technical driver, there were many features that had to be addressed in order to handle customer needs.  The rewrite effort moved the software from Windows 7 to Linux.  Although this was a major rewrite, we were able to use core sections of the business logic.  This was an important part of the architecture discovery phase.  It was still a major undertaking, but we didn’t have to recreate logic that had been around for 30 years. 

Conclusion 

No matter how you decide to handle your Legacy Software, automating the testing and building of the software is a requirement.  Whether keeping legacy software or rewriting legacy software much of the work is the same, however the objectives do change.  The work being performed (keep the legacy software or replace the legacy software) is determined by the end goal.  If the ultimate objective is to keep the legacy software, decisions made while architecting the solutions will most likely drive to different conclusions than if the objective is a rewrite.   

References 

• Re-Engineering Legacy Software, Chris Birchall, 2016
• Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, David Scott Bernstein, 2015
• Working Effectively with Legacy Code, Michael Feathers, 2005
• History of Linux, https://en.wikipedia.org/wiki/History_of_Linux

In this ‘digital revolution” we live in now, change is here to stay. Whether the business is ready for it or not, the tidal wave of technology is rapidly changing how we do business internally and externally. If you are in a leadership position within technology you are probably facing multiple obstacles and feeling pressure and demand from the business. Business models that carried companies to the 21st century are not the models that will carry or grow the business in today’s world. The pandemic ignited a fire that forced companies to evolve their mindset about how they are utilizing data, automation, and their employees.

In 2 short years, we watched business leaders who consistently shut the door on any remote work, be forced to open that door. According to Forbes, 74% of professionals believe remote work will become the standard. Companies like LinkedIn, Facebook, Slack, and several others have begun to announce their remote business model to attract better talent. When we speak with CIOs and management, we often get asked “Are you seeing people go back to the office yet?” Right now we are seeing a mix of remote and hybrid work with very few companies demanding an in office presence from their IT staff to help with retention. From a candidate perspective, we can tell you that we constantly get asked if the project can be worked on remotely. The top talent has the option to be picky. They can work remotely for a company in Dallas, Austin, or anywhere else now that the landscape has changed.

So what’s next?

For many organizations, they are looking at the CIO to help generate more business value with new technologies and processes. Promoting employee count is a thing of the past. Companies are not boasting about how many employees they have anymore because they learned that they could operate more efficiently throughout the organization with the help of the CIO implementing new strategies and processes with technology. Many companies are transforming the business from the ground up while some had good momentum going into the pandemic and they are just adding to the plan that was already in place – it just got moved up quicker with far more urgency.

CIOs now have the attention of the CEO, Board, and Investors more than ever before. Like anything else in business, you have to take advantage of timing. For years, CIOs have tried to convince senior executives of the importance of modernizing the business through technology. This has traditionally been shut down with various reasons and an older mindset of business that worked in the past. As technology continues to spread into the overall operations of the business we have to ask ourselves “Is the CIO the new COO?

What to expect?

Expect increased budgets for the IT organization, more demands coming from the lines of business, and take more responsibility and leadership throughout the organization. We are beginning to see more management roles over each division within the IT organization to help implement new processes, procedures, and build KPI’s to manage the workload. Upper management wants to be able to track and measure progress. Since they can’t do that dollar for dollar they will want to see some kind of measure of success. Amazon lost money for years but Jeff Bezos had the ability to show the progress they were making and communicate the long term gains they would come to realize. Developing a KPI driven IT organization allows the CEO, Board, and Investors to feel more comfortable about allocating more budget to the organization. In 2021, all companies are technology companies, but they need someone in leadership to show them the roadmap and open the dialogue of what’s possible rather than what’s unknown.

Brent Fields
Partner

Managers and executives are becoming increasingly aware of the problem of “Bad Code.” A few relatable questions are: Why are the new features taking so long? Why are we dealing with so many customer issues? Why is the turnover in our IT development group so high? All of these issues can be attributed to bad code, but what is “Bad Code” exactly, and how is it affecting the business? Asking ten developers what bad code is might result in ten different responses. In order to understand how “Bad Code” is affecting a business, the terms “Bad Code” and “Good Code” must be accurately defined.

What’s the Difference? 

The difference between “Good Code” and “Bad Code” can be understood most easily in a comparison. Below is a comparison chart between good coding practices and bad coding.

Easily Understandable vs. Difficult to Follow

Code that is easily understandable allows developers to quickly and accurately make changes to the codebase in order to add new features and resolve customer issues. However, difficult-to-follow code has multiple problems. Bad code makes new features difficult to implement, customer issues are difficult to resolve, and onboarding new developers becomes a lengthy and difficult process.

Logically Separate vs. Inseparable Modules

Logically separated modules allow many developers to work on different aspects of a solution without interfering with each other. However, inseparable interdependent modules make it impossible for developers to make any changes without a comprehensive understanding of the application. This causes longer onboarding for new developers, decreased performance of the dev team in general, and developer dissatisfaction.

Testable vs Untestable Code

Testable code with unit and integration testing is vital to give developers confidence in adding or updating features. Untestable Code lengthens the development cycle by requiring extensive manual testing and regression testing for code change. Fragile tests are sometimes worse than no tests at all because they will require the developer to maintain multiple codebases without any discernible benefit. Tests that have to have extensive rewriting to facilitate any code or business logic change need to be refactored to test modules in a more robust way.

Descriptive vs Arbitrary Names

Descriptive naming conventions add to the readability and maintainability of the code. Arbitrary names cause confusion.  Idx, count, temp, buf, etc. All these names devoid of context are meaningless. A new developer will have the question of what are we indexing or counting? Temporary what or buffer for what?

Well-documented vs Poorly Documented Scripts

Well-documented means appropriate for the situation. If a class or module is very well named and has a clear control, flow documentation can be brief. If it is confusing, difficult or requires extensive domain knowledge, then documentation should reflect the complexity.

Documentation is never a replacement for good architecture and clear code. External APIs and interfaces must be thoroughly documented or there will be ongoing issues with code integration. Poor documentation may still be substantial but can be out of date or trying to cover for poorly designed code.

Up-to-date vs Depreciated External Packages

External packages are very necessary to avoid “reinventing the wheel” on every project. Keeping packages up-to-date and avoiding deprecated APIs is essential to successfully integrating external code into a project. Packages that are ending support or no longer being developed need to be replaced. Out-of-date or deprecated external dependencies will reduce the effectiveness of developers by causing them to spend inordinate amounts of time understanding and debugging code they did not write and for which they are not responsible.

Fixed vs. Flexible Architecture

The architecture of a project is something that does not spring into being fully formed. By necessity, the architecture needs to be flexible to changing business needs and requirements. Refactoring architecture to reduce complexity is essential whenever business logic significantly changes. Ignoring the need to update architecture because of the time required is taking on tech debt that will drown the development team and cause high turnover. No one wants to be responsible for risky architecture changes once the problem has gotten overwhelming.

After looking at some of the comparisons between good and bad code it is clear why good coding practices are so important. As technical debt grows from bad coding practices, feature development slows to a crawl, customer issues become more common and more difficult to resolve, and finding good talent to work on the codebase as well as retaining talent becomes completely unmanageable. Solving this problem is difficult without being able to explain why good coding practices are necessary for a healthy growing company. Pointing out the comparison between good and bad practices allows non-technical stakeholders to see why they must budget time and resources to maintain a good clean codebase, in order to keep new features easy to develop, manage customer satisfaction, and retain talented developers.

-Kenn Williamson, Senior Software Developer, SEQTEK

Technology is everywhere. Software runs devices like phones, vehicles, buildings, manufacturing processes and just about everything in between. Building software is difficult. Writing code isn’t necessarily difficult, although it can have a steep learning curve for new developers. But there is much more to developing software than the coding aspect of it. Three of the many reasons as to why developing and ultimately delivering software is difficult are: a development team misunderstanding the purpose of the software they’re building; the business or customer not knowing what they want (or their own processes); and developers selecting less-than-optimal technologies as opposed to what is best for a particular project.

What is the purpose of software? The purpose of software is to guide and automate processes. It is a crystallization of a workflow into a repeatable action. Why is this important? Because software can’t fix a broken process. People want to use software to “save” a business but this inevitably ends poorly because the software only makes it worse. Software will make a “good” process better by streamlining and simplifying the workflow. Software will make a “bad” process worse by further locking the user or business into poor practices that are counterproductive.

A related problem is that business groups and customers often don’t know what they want. Worse, they often don’t understand what makes their own process function or succeed. A development team is only as good as the requirements communicated to them by the business. Even if the business has a successful process in place, translating that into good software is difficult. Development teams have to sometimes tease the design out of the stakeholders by asking questions and proposing ideas. Stakeholders will have a lot of ideas and it is the job of the development team to winnow those ideas and prioritize them to ensure only those that provide value to the business and its users are completed. The client will often resist this because the priority they place on certain, less valuable ideas is often greater than the particular ideas important in the overall design. Managing expectations and timing as well as prioritizing the most important features first is another reason why building software is so difficult.

It isn’t only the business groups that make the software development process challenging. Developers have their own role to play in the problem. Software developers are people too, and they have strengths and weaknesses. They have technologies they are experienced with and other technologies which may be unknown. This causes many difficulties in creating successful software because often, developers will pick the technology they know rather than the one that would have the most practical benefit to their current design. Of course there is the opposite end of the spectrum where developers will prioritize new and shiny technologies for a problem that can be solved with existing well-established practices as well. Both of these can cause a software project to be deemed a failure without even realizing it until the end.

In conclusion, software development is tough. The problems mentioned above are only some of the considerations that make it so difficult, but they can be overcome. Business groups and customers have to find the development team that will balance their experience with new technologies, help them to discover the optimal design, and fulfill the true purpose of software. They must take a successful business practice and create a software system that allows that practice to work in a repeatable way.

– Kenn Williamson (Senior Software Engineer, SEQTEK)

There is a certain amount of arrogance that exists for someone to believe they can codify a business process they know nothing about in a very short period of time. This is the world of a software developer. Show any software developer a business or job, and they immediately start thinking about how a piece of software can do the work faster, better or cheaper.

Software isn’t magic—it takes jobs that either are or were or could be done by humans and makes them repeatable so that error is reduced or efficiency is increased. More output with less input while not forfeiting quality is how productivity is increased. It was just this combination of computing power, the Internet and software that caused the productivity model of economists to break in the late 1990s.

The definition of hubris is the characteristic of excessive confidence or arrogance, which leads a person to believe that he or she may do no wrong. Hubris is what happens when the excessive confidence of developers careens off into the ditch. Successful businesses are the culmination of a unique set of ideas and talents that fulfill a need of their customers. Over time, successful businesses collect quality people, products and processes, regardless of the software they use. Oftentimes they can become routine and out of date, however we must also remember that successful companies are successful for a reason. Some of the factors of success may be different than many business norms. Software developers must realize and act with the knowledge that the people within the business are the experts (subject matter experts or SMEs) and it is imperative that continual communications with these individuals and groups exist throughout any project. 

Software Development requires a lot of communication. Requirements gathering is what most think of when we discuss software development communications. However, the most important communication is about validating the completion of something. Project delivery is a collection of touchpoints with SMEs correcting a path to completion. Continually demoing software is important to ensure any deviation from a successful delivery is corrected as soon as possible. Communications must also be in the language of the user, which is working code.

Business, technical and management groups must be able to have real conversations without sarcasm, anger, pettiness, etc. The interactions must be healthy, driving the entire process to success. Humility from the software development team is a key characteristic to success. Expectations of completeness and correctness from any information gathered at the beginning of a project without continual communications throughout the project by key SMEs is a recipe for failure. In addition, management must serve developers in every way to add clarity, consistency, remove obstacles, etc. Developers (really all humans) will stop or slow when there is confusion—keeps us from getting eaten—and one the most important jobs of both software development and business management is to eliminate confusion.

An agile project development process embraces this reality and with humility, actively pursues a solution that provides value to its customers. The “Twelve Principles of Agile Software” takes this into account and lays out these principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals.
• Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development.
• The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity—the art of maximizing the amount of work not done—is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

After 30 years of software development I have found that hubris is the enemy of success and both the SMEs and developers must work together knowing that only through ample communication and teamwork is a successful software development project delivered.

– Hank Haines (CEO of SEQTEK)

68% of companies are more likely to have a marginal project or outright failure than a success (“Study: 68 percent of IT projects fail”).

Budgets are blown up, timelines get dragged out, and the project doesn’t seem to come out like it was originally planned. So why? Over the last 20 years, SEQTEK has been brought into various situations in different industries and here are some of the common issues we’ve seen in software projects.

1. Poor Requirements Gathering

This can be attributed to a number of things. Many leaders assume that developers have the information needed for what the business is looking for. The developers may have an idea of what the business is looking for but they aren’t mind readers. The lack of user input creates miscommunication of the true expectations set ahead. Pair this with poor project management and you can see how this will cause a failed project before it’s even delivered.  

2. Constant Distractions

Most development teams are forced to put out fires from previously flawed projects that they might not have been a part of. This takes their focus off the new project and constantly pulls them back to the older projects. This causes the backlog to build up and it’s a constant back and forth that puts a lot of stress on developers, especially when they can’t dedicate their time to completing the current project’s objectives.

3. Employee Turnover

It’s no secret developers are in high demand and with the average turnover for a software developer around 2 years, projects get shelved if/when certain team members leave the organization. A common reason developers leave is because they become stressed out, overwhelmed and unmotivated. Companies have been left in the dark when a developer leaves the company which often creates a huge knowledge gap and makes it even harder for the next developer to step in and take over.   

The truth is that successfully completing software projects is difficult. You can’t make it easy, however, you can adopt certain processes that are proven to work which allows your team to remove roadblocks quickly and minimize risks. We have worked with leaders in just about every industry and no matter what the industry, these common challenges in software development can create infighting, cause unnecessary stress, waste time, and cause excess spending. To help combat these challenges, make sure your business is properly gathering requirements, have a product owner or project manager that’s responsible for managing those requirements, and give developers the tools and resources they need to be successful.

– Brent Fields (Managing Partner, SEQTEK)