Rich Internet Applications (RIA)

“Refactoring Large Software Systems” — an article by Sibylle Peter (Canoo Engineering AG) and Sven Ehrke (Canoo Engineering AG), published in Methods & Tools, Winter Edition 2009.

Refactoring a software system means to refurbish it internally without interfering with its external properties. In his famous book Martin Fowler defines refactoring as follows:

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. [Fowl, p. xvi]

Fowler describes how to refactor code in a controlled and efficient manner. Although we frequently use these techniques to refactor large software systems, this article is not about refactoring techniques. It rather treats large scale refactoring of systems that suffer from being stuck in an infeasibility stage, which means that it is no longer possible to implement new features and that every bug fix leads to several new bugs.

In this article we describe the different stages of a refactoring project. Before a refactoring project is actually started, an assessment and an in-depth analysis are made which result in a list of findings. Ideally, these findings will be translated into a master plan, which defines WHAT should be refactored. This master plan helps to keep the overall picture of the refactoring project in mind and to divide it into several sub-projects or refactoring parts. Once the master plan is defined we use an iterative approach to tackle the individual refactoring steps.

Before describing this approach we will first have a look at the life path of applications in general, followed by the prerequisites for refactoring projects. WebInvest, our current refactoring project, will be used as example throughout the article. WebInvest is an advisory tool for investment relationship managers. It enables them to simulate trading and to analyze a customer’s portfolio against investment strategies. Read on!

.

The life path of a long-living system

Session title: Refactoring of Large Software Systems revised
Speakers: Sibylle Peter, Sven Ehrke – Canoo Engineering AG

First observation: This is a very well attended session, which reflects the fact that refactoring, whilst not the most glamorous of tasks, is obviously very important to a lot of developers.

The speakers describe the key lessons learned during a very challenging refactoring undertaking at a major bank. The project essentially involved trying to clean up software, the internal dependencies of which had gone out of control over time.

One of the key lessons learned: Keep it Simple, Stupid.

Options:

• Do a huge refactoring at some point once it has been recognised that costs per features have sky-rocketed. This is obviously not the recommended approach, but it is often the only option available.
• Do refactoring incrementally per release
• Do refactoring constantly

The costs of the project are pretty shocking: 6 persons for around a year. I could imagine this was a pretty sobering message for many members of the audience.