Building modern software is still a largely manual and complicated undertaking. In many respects, modern software facilities are beginning to look a lot like telecommunications systems—many very complex internal systems and processes, with application front-ends that look simple to the end user. The advent of web deployment has profoundly changed software development.
Added to this complex mix is an increased number of platforms and the associated service access routes of desktop, server, mobile, etc. Indeed, modern IT systems are increasingly complex service-supply chains, starting from the end user (often sitting in front of a web browser), through the middleware layers, and all the way to the data layers. Keeping all the stakeholders and users of these services happy is a difficult task.
The widespread use of Agile techniques and methodologies might even be said to increase the growing complexity of software systems! The Agile approach typically breaks development projects into short duration "sprints," each of which is composed of a number of weeks. Each sprint can be viewed as an effort to condense a large project into a collection of mini-projects. Often, a sprint consists of what might be called a vertical slice of the finished system; that is, a complete or nearly complete feature. The intention is usually to combine the results of all the sprints into a wider project. The use of sprints in this way helps to reduce the overall risk of a given project. While offering a degree of risk mitigation, Agile approaches in my experience do little to simplify the development process. Indeed, the Agile approach may even make development more expensive!
The advent of mobile platforms has done little to change the overall complexity or improve the associated risk profile. As a developer myself, I find it comforting to think that software development is likely to remain a challenging career choice for many years to come.
With all these platforms and development processes, there is of course the ever-present issue of legacy code management. In this article, I'll demonstrate a simple use of Python for calling C++ programs.
Legacy Code Never Goes Away
One important aspect of system integration is the use of component legacy software. If company X has spent years developing custom-built C++ code, the management of company X is unlikely to want to throw away that code. Indeed, there may be no debate on this issue if the organization's end users are already making extensive use of the legacy code.
The issue of legacy C++ code is particularly relevant in the financial services and telecommunications industries. Many organizations in these industries have been coding in C++ for years and have amassed a substantial base of critical business process programs. If company X has such a large C++ codebase, that code must remain usable for its projected lifecycle. How can we protect this legacy code investment?
Let's examine one way to protect the legacy code: integrating the invocation of C++ programs from within a Python environment. Python offers a number of C++ integration facilities. The one we'll review here might be called the "glue logic" approach.