Legacy Applications

Introducing IoC To An Existing Application (Continued)

(This is a continuation of a previous post)


In the previous post, we adapted our existing code to allow the use of an IoC Container, and prepared the container so it is ready to use.  In this post, we put that foundation to work and start altering our logic.
Install Service Locator
When coding new applications, Inversion of Control (IoC) is best done using Dependency Injection, or DI.  However, DI assumes all necessary classes are registered with the container and available for resolution.  When converting an existing application, it is not practical to convert all necessary classes to DI in one step.  Trying to do so can dramatically increase the scope of the work, making the conversion project more difficult and possibly extending it beyond a single sprint.

In order to avoid the requirement of converting the entire application at once, we introduce an intermediate step of using a Service Locator.  Using the Service Locator pattern allows you to convert objects to the IoC pattern slowly over time instead of requiring a massive conversion effort.  Once an application is fully converted to Service Locator, it is a trivial step to further convert it to Dependency Injection.

The Service Locator is a static class that is referenced from all parts of the system (this is the part that Service Locator detractors object to).  As such, it needs to be located in a central project that can be referenced by all classes that need it.  Depending on how your IoC container works, this project may also need to be able to reference the projects where the Interfaces and Classes are kept. If you have a large solution, finding a good place to put the Service Locator can be one of the most difficult parts […]

Introducing Inversion of Control To An Existing Application

How to retrofit an existing system to use Inversion of Control and Dependency Injection, without the cost of a rewrite. Reduce maintenance costs for legacy systems.

Tools for Updating Brownfield Software

I find myself depending on the following tools continually while working with Brownfield Software or new development.  They are both excellent additions to your own toolbox.
NCrunch Tests
NCrunch is an excellent unit testing tool that continually runs your unit tests while you are working.  It runs in the background and will periodically build the application just as you have it.  Assuming it builds, NCrunch will then run all the unit tests that are affected by any changes you may have recently made, then show the results of those tests.

When I describe this tool to others, their first comment is usually about “how annoying it must be” to have tests constantly running, and at first it was.  However, I put the NCrunch display to the side of my left-most monitor and just let it sit there.  I quickly became tuned to the color red in that window, so that now as I’m coding if something turns red in that window I notice it.  As long as everything is green, though, it fades away out of site.

This tool is excellent in detecting when I break business rules that I’ve forgotten about.  I was recently picking up a project that I haven’t done anything with in a quite a long time.  I opened the project, all my tests were green, so I started coding.  I made a small change to the code an a few minutes later many tests started turning red.  I then remembered there was a quite complicated set of approvals that need to be acquired before a particular business process can be completed and my new code was ignoring those requirements.  Just in that instance, NCrunch paid for itself.

There are many other features of NCrunch that […]

By |October 22nd, 2014|Legacy Applications, Reengineering Existing Systems|0 Comments

Automated Testing for Brownfield Software

Implementing modern automated testing on software requires that the system in question be broken up into pieces.  This is not to say broken into different systems, just that the code that makes up the entire application need to be composed of distinct pieces, or modules (or classes, or components, etc.)  When things are properly designed, an application will be composed of many different components, and they all work together via interfaces – the information they pass among themselves.  Current automated testing approaches can then take each module and feed it different values for the various interface elements, and check to see that the component behaves in the proper way.

For example, say we have a system that is supposed to accept a data feed (from another system, not a person), validate the data in that feed and record any errors, then email one person on success or a different person on failure.  We could break this system into the following components:

Input reader – reads the incoming data (i.e. in XML) and breaks it into the distinct data fields
Data Validator – looks at each piece of data to ensure it follows business rules
Error Logger – saves any errors found (to text file, database, or elsewhere)
Emailer – creates and sends emails

With the system broken into these parts, automated tests could feed the Input Reader different XML files (some valid, some invalid, some incomplete, etc.) and ensure it handled them all correctly.  A different unit test could create a Data Validator and send it samples of valid and invalid data, and so on.

When working with Brownfield software, introducing automated testing can be one of the most difficult parts because the code is normally a Big Ball of Mud.  In order […]

By |October 21st, 2014|Legacy Applications, Reengineering Existing Systems|0 Comments

Updating Legacy VB.NET Applications

Legacy applications are not always extremely old. Sometimes they have just been ignored for a while and in order to reduce support costs they need a polish.
First Things First: Project Options
If you’ve ever worked with a VB.NET project that has been around since the early days of .NET 1.1, you probably had a lot of cleanup to do before applying any of the latest technologies. If this effort is taken haphazardly, it can result in a mess that is difficult to clean up. Taken in the proper order, though, legacy VB.Net can be updated quickly and easily.
Option Explicit = On
The first thing to do is ensure Option Explicit is turned on. This is a property in the VB.NET Compile project page that requires all variables to have an explicit declaration – a DIM statement. When this option is set to Off, variables can be created and used on-the-fly without a formal declaration. This is bad because with Option Explicit = Off, a simple typo in a variable name will cause the compiler to create a new variable by that name, resulting in bugs that are very hard to find.

Note that Option Explicit can also be turned on and off in code! Before setting the project property, scan through your code for “Option Explicit” to see if there are any landmines waiting for you.

To minimize the confusion, set Option Explicit for one project, then build and fix any errors. Normally it only takes a few “DIM” statements to get things working again. Then move on to the next project, making sure to check in your code after each build so you have a “check point”.
Option Strict = On
After setting the Option Explicit = On for all projects, […]

By |October 10th, 2014|Legacy Applications, Reengineering Existing Systems, VB.NET|0 Comments

Brownfield Software Development – A Step by Step Guide for the Enterprise

The goals of brownfield and greenfield development projects are different.  Greenfield projects develop a new application as quickly as possible to address an ongoing business problem.  Brownfield software development projects, however, are concerned with enhancing existing code to solve a business problem, while keeping the legacy application available.  It is the second part of that sentence that is the key to the value of brownfield development over greenfield – you can fix the plane while it’s in the air.

These different goals require a different management and technical approach.  Let’s assume we are adding a new feature to an existing application.  This is an application that was developed a long time ago and has been working well, but now the business requirements have changed so we must add a new feature.  Moving our legacy application towards Service Oriented Architecture is our long term goal, so we will be also move the application in that direction while adding our first feature.
Step 1 – Introduce Inversion of Control
If the legacy application does not have some form of Inversion of Control, this should be introduced first.  IoC is an common architectural pattern that makes applications much easier to build and enhance by breaking them up into smaller pieces that work together.  Each piece can be replaced with something more functional at any time without affecting the rest of the system, as long as the inputs and outputs remain the same.

One type of IoC is called Dependency Injection.  This is an excellent approach to use when building applications from scratch, but can require a lot of work when trying to introduce the pattern into an existing system because the pattern must be used everywhere – it cannot be slowly introduced to […]

Greenfield and Brownfield Application Development

To quote Marc Andreeson, “Software is eating the world”. To those in the technology industry this should be self-evident since we see new software applications being created each day. A question rarely asked is what happens to all that software as it gets older and needs to change to meet new market demands. To answer this, we need to split software development into two categories: Greenfield Development and Brownfield Development.
Greenfield Application Development
Greenfield Development refers to brand new applications – ones that start from scratch (or as Wikipedia puts it “…lacks any constraints imposed by prior work”). This can mean a new application that solves a previously unaddressed business problem, or a system that completely replaces an existing system which is inadequate in some way.

In greenfield development, the feature set and interfaces are dictated only by the problem being addressed.  The different aspects of the problem can be solved in any way the development team sees fit, as long as it solves the described problem.

Greenfield development can be quite time consuming since it requires all aspects of the new system be defined and constructed.  For new applications that are meant to replace something that already exists the process can be just as lengthy.  Though it would seem that when replacing an existing application much of the work has already been done, the very fact that the existing system needs to be replaced indicates that the current system is inadequate, therefore duplicating what is already there is insufficient.

Due to its very nature, a greenfield project can only begin adding value to the business when it is complete.  While still in process, there is insufficient functionality to provide any benefit, and can even do harm if the system […]