Surprisingly, refactoring is often not a technical challenge. Usually, teams can accurately diagnose inefficient code design. Typically, they also have ideas of what to do with it, what tools to use, what refactoring transformations to apply. If they have sufficient time and budget at their disposal, they would probably get things done.

When you think about refactoring, you might think about transformations such Extract Class or Introduce Polymorphism. They are important in transforming your everyday work with the code. In this article, we focus on something more complex – the strategic code refactoring. This distinction was introduced by the BNS IT consultants as part of the method called Natural Course of Refactoring – a process that they developed to work with legacy code. For more on this, see the Natural Course of Refactoring - and Refactoring Worlflow.

Refactoring, however, is mostly an organizational venture that must get approved and funded – and that needs to be managed in the long term. This article describes how we approached this subject in the design of an e-banking system at Nordea Bank AB S.A. in Poland.

Context

As a result of business decisions, Nordea IT Poland (currently Nordea Bank AB S.A. in Poland) ceased to develop their e-banking system on the Polish market, and kept the product in the Baltic countries only. After some time, the following difficulties began to appear:

• Business clients would wait for the requested functionalities for a long time – on average, starting from the request, it took several months to complete;
• Some requests were impossible to execute due to the technological constraints of the e-banking system;
• Clients would sometimes request individual functionalities developed in newer technologies from local providers. Nordea IT Polska  had to then maintain and integrate these functionalities into the banking systems.

At the beginning of January 2015 we started our cooperation (Michael Bartyzel /BNS IT and Nordea IT Poland). The objective was formulated as follows: To shorten the time needed to provide a new functionality to 30 days. To give this new initiative a more tangible dimension in the organization, we named it Action-30.

What’s the reality?

When you begin to work with an organization in the context of a specific subject, you usually encounter many points of view. From the very beginning, it is extremely important to realize that these are just different narratives of the same reality and none of them is more real than others. Within the same organization, you talk to different people who often present contradictory information, but each of these is consistent and seems to be justified.

Nonetheless, this information thicket has a certain repeated scheme in itself – the interlocutors usually talk about someone or something else: about other departments, associates, customers. They rarely talk about themselves, for example:

• Teams are late,
• PO should know what they want,
• Requirements are not clear enough;
• Customers change their mind;
• Security always blocks implementation;
• etc.

There is a way of expression that we can call the message You. If you are now wondering “so what? people talk this way”, take a look at the visualization of this way of communication in Figure 1.

Figure 1. The message You.

When all you have is information from your interlocutors, provided in the form of the message You, you cannot  diagnose the needs of a given organization. If everyone speaks exclusively about someone / something else, the only thing you find out is the opinions that the interlocutors hold about someone / something. Moreover, this form of communication suggests that “the others” are to blame for the existing problems. In such a situation, the possible solutions are “fight with them” or “run away from them”.

In the course of diagnosing the organization's situation, the best option is to manage a conversation in a way that will enable you to obtain information in the form of the message I. These are statements such as: I want to..., I do not want..., I miss..., I need..., I like it when... For example:

• Instead of Teams are late you will hear:
  • I want to close the projects on time,
  • I don’t want to work under time pressure,
  • I want to be informed about emerging problems quickly.
• Instead of PO should know what they want you will hear:
  • I don’t quite understand why we are doing this product,
  • I need more acceptance criteria for my tasks,
  • I want to have tangible influence on the development of this product.

Again, take a look at the visualization of communication using the message I (Figure 2).

Figure 2. The message I.

Note that this time the same form of expression suggests possible solutions for the organization. Moreover, exposing the individual needs of people, teams or organizational units is an opening for cooperation oriented at meeting those needs.

The sources of the problem

The first step in the search for the causes of the problems with the development of the e-banking system was to prepare a general RCA (Root Cause Analysis)[1] diagram.

Figure 3. RCA diagram.

The initial symptom that we began the analysis from was: “Changes take too long or are impossible”. We were looking for a reason for a considerable number of coinciding symptoms and loops. An example of such a loop is presented in Figure 4.

Figure 4. A loop on the RCA diagram.

Using the diagram that we developed, we pointed out two root causes of the  “Changes take too long or are impossible” problem:

• Using the Struts 1.2 backbone – the system with which we worked was developed almost ten years ago. Originally, it used Struts 1.2 – the backbone for creating web applications; in 2015, this solution was already archaic and significantly limited the ability to create modern web applications.
• Excessive code universality – the system was created by many people and was implemented in several countries, which – depending on the banking services regulations – entailed that some functionalities slightly differed from each other; these variations have been implemented by placing conditional instructions for the user’s view, application services, and some domain services. As a result, the code had a relatively high cyclomatic complexity[2].

The analysis of the architecture

Figure 5. The analysis of the architecture.

The next step was a session organized to diagnose problems associated with the existing architecture. These points were perceived as key, based on their direct and largest impact on the time needed to deliver a given functionality:

• The need to respect the Struts 1.2­ architecture – this architecture was not designed according to the convention over configuration paradigm, which lengthened the time needed to add or modify an individual functionality.
• Business processing on JSP pages (rare cases) – this way of code writing is extremely unfriendly for rapid introduction of changes.
• A large amount of unused code – since the system is no longer implemented in Poland, the code associated with it is no longer used and is unsupported, but it still exists in the code baseline.
• Strong dependence on other systems – this aspect made the implementation time longer, especially when a new requirement caused a change in the core system.

The analysis of the software delivery process

Figure 6. Mapping the software delivery process.

At the stage of the analysis of the software delivery process, we focused on individual activities between the need reported by the business and the implementation of the software. In the first run, we were looking for the instances of bottlenecks in the process, as well as those types of business requests which were most often rejected because of the technological limitations. These are the elements that had the biggest impact on the process flow:

• Multitasking – developers were involved in more than one project; in extreme cases, to switch between tasks from different projects including a switch between different environments to start carrying out the tasks effectively would take them from 30 to 60 minutes.
• Ineffective meetings – the number of projects implemented simultaneously meant more meetings.
• Developers’ specialization – this hampered the cooperation and caused large workload for individual developers.

The work method

From the very beginning, we were aware of these constraints:

• Action-30 cannot hamper the ongoing projects.
• Initially, five volunteers can take part in the project.
• Each of the developers can devote one day a week to working on Action-30.
• We have to manifest the business benefit from the investment in refactoring as soon as possible.
• The method of work should be interesting and engaging, because working on Action-30 is an additional occupation.

Eventually, we decided that we would work in a'la Scrum. A'la because it was not proper Scrum. Instead, it was a casual “about” variation. Our method called a’la Scrum was more about PR and motivation than using the real Scrum framework. The assumptions for the work method were as follows:

• The entire team works on Action-30 only on Thursdays.
• A’la sprint lasts one month, i.e. 4 Thursdays.
• A’la sprint is followed by a retrospective, an overview with possibly the biggest number of stakeholders which involves planning another a’la sprint.
• We work on tasks in pairs.
• In consultation with the Head of Department we made a joint commitment to consistently avoid unproductive meetings.
• To help the team succeed, while planning we would strictly decompile tasks into components of no longer than 4 hours.
• Each a’la sprint has a specific and measurable goal.

A’la sprint 1

The first a'la sprint was planned with a set of organizational tasks and only one technical task. It consisted of separating from the e-banking system a secure web service for sharing the data for one of the views.

Why was there only one technical task for 20 man-days? First of all, in order to have an almost guaranteed success of the first sprint. Initiatives such as Action-30 are quite unstable in the organization. Even a small fault in the ongoing projects can effectively prevent the team for working on a new initiative as planned. For the future benefit of the entire project, it is better to have one small success than big plans and enthusiasm that fades away after two weeks.

Retrospective

The summary after the first a'la sprint was as follows:

• The goal has been achieved.
• Working in pairs feels very good.
• Meetings had structure and depths. From the perspective of their duration, there are in fact less meetings.
• We managed to do more than planned.
• Let’s introduce more collaborative planning.

Observations

The first thing that immediately drew our attention was that the Action-30 projects begins to live a life on its own. Other workers talk about this initiative over coffee. They are interested in it and ask if they can join.

Surprisingly, the team managed to do more work than it had been planned. This is because individual developers devoted more time to working on Action-30 than the planned Thursdays. This fact alone is very interesting. Of course, none of the then projects suffered. On this basis, we came to a conclusion that if something is fun and interesting, people will find time to do it. Moreover, this “extra” time does not require any formal proceedings and schedules. People take their own initiative to introduce local optimizations in order to work on what they really like.

The first a'la sprint highlighted the immense value of a manager in projects of this type – projects initiating a change. A great team can cope with the technical tasks, but for the organizational tasks, especially those that change the way of cooperation between different bodies and break down the silos, there is a need for help from someone who knows the formal and informal decision-making paths within the organization. With the help of the manager,  the team reduced the number of meetings needed, and initiated other channels of communication with cooperating departments.

In the context of the team, we also began to be see  the emerging team norms:

• We work in pairs over one task.
• We celebrate success.
• We avoid unproductive meetings.
• …

as well as refactoring guidelines. These were in the form of a description of typical tasks and problems and their solutions. These guidelines structured the team’s knowledge. They were intended also for the future team members.

A’la sprint 2

Starting from the second a'la sprint, we planned to regularly show the business benefits of refactoring to the stakeholders. Although refactoring means a change in the code structure without changing its external functionality, it is virtually impossible to “sell it” without indicating the positive influence on the business results. We used two approaches:

• escalation of the organizational benefits of refactoring – we indicated the measurable benefits of refactoring to the organization e.g. shortening our development time.
• architectural slices of customer-centric features – refactoring tasks were always combined (in a reasonable proportion) with improving/adding valuable functionalities.

Report – A basic tool to communicate with the organization

During the initial analysis we pointed out to the large amount of unused code. As mentioned earlier, the system has ceased to be developed on the Polish market, but the code associated with the specificity of the Polish banking sector was still present in the core. In addition, the code was not wrapped ( “encapsulated”), but arranged inside algorithms. This meant that to manage the volatility and the expansion of the system, instead of adding new implementations, the team had to add conditional statements inside the methods.

Figure 7. The consequences of removing the unused code.

To communicate the message to the decision-makers, we decided to express the benefit of removing the code in the language of money and schedules. For this purpose, we prepared a sample code where we measured the number of rows and the cyclomatic complexity before and after the code associated with the Polish market is removed. Although measuring the number of code lines gives little information to a developer, it is very informative for a non-technical person, as it is synonymous with the size of the software.

The cyclomatic complexity of code is much more interesting. It provides information on the number of decision paths in the code and is therefore also a measure of the number of tests necessary to cover the functionality. It turned out that after the removal of the “Polish” code, the complexity of the sample decreased by 15%, which in turn translated into the reduction in the number of tests required by 29.

At this point, we indulged in a little breakneck estimate extrapolation – by approximating the results of all similar samples tested in the code and converting the reduced number of tests on the days, we received an approximation on how many man-days could be saved through the proposed refactoring. This is definitely something to be heard…

In a large organization, reports are the primary communication tool. Once published, the report is transmitted between the mailboxes like a rumor in the kitchen, and the information contained there reaches a very wide audience. For this reason, we prepared a report with the described estimates and emailed it to the nearest supervisor. As expected, the information about the benefits of refactoring has been heard and understood.

Let’s show the business value

The second method of operation was to combine refactoring tasks with tasks related to improving/adding valuable functionalities. Although by definition, refactoring is about making the code beautiful without changing its functionality, for the organizational and financial reasons it seems necessary to combine it with adding more value to the product – and usually preferring the latter activity.

We decided that to showcase refactoring to the business, we would develop one of the features that had been previously requested by the business, but turned out to be impossible to implement due to technological reasons.

As mentioned, one of the main causes of problems with the provision of the software was the use of the Struts 1.2 backbone – we decided to try AngularJS.

Figure 8. Showcasing refactoring to the business.

Because the team did not have any previous experience with this technology, we primarily focused on specifying the user views in an accurate way, and then we invited a JavaScrpit specialist for a several hours workshop. His task was to prepare the AngularJS views and to provide the basis for its construction and operation, so that the team was able to implement it in their system.

This way, the developers could focus on how to refactor the backend, style the new views and integrate them with their e-banking system. It drastically reduced the threshold for entering the new technology and made it easier to achieve success. At that stage, our priority was to promote the need for refactoring, not to migrate to a new technology.

The business wants more

Since then we planned other a'la sprints to enable us to join refactoring with showcasing this refactoring to the business –  usually in the form of functionalities that the business desired the most.

While cooperating with us, the manager ensured that as many potential stakeholders as possible took part in the a'la sprint reviews. The visible effect of this action was that the project managers asked to provide further “nice” functionalities. At the same time, a number of developers from other teams joined the Action-30 initiative, so our internal marketing was successful as well.

The most surprising information came when we learnt that the “top management is significantly interested in Action-30”. After verification, however, it turned out that it was, precisely speaking, a rumor. Nonetheless, it was advantageous for our initiative. We understood then that Action-30 and its message made its way to the awareness of the organization and began to live their own life.

How did it end?

As a result of the movements at the level of corporation, the organization decided to gradually close the development of the e-banking system in Poland. Therefore, we were unable to bring the Action-30 to the end. Nevertheless, the proactive attitude of the team was noticed, because they received the task to take over the important projects in the “modern” technologies from foreign partners.

The team mainly stressed the fact that this entire initiative showed that “yes, they can”. It showed that it is possible to initiate and promote a major change in a large organization that creates sensitive software. Developers learnt that they have influence on the decisions of the organization, and that they can break through with their technical needs. What more is there to want?

Figure 9 Action-30 summary prepared by the team.

The article has been written with the permission of Nordea Bank AB S.A. in Poland.

About the Authors

Michał Bartyzel – For more than a decade, a software developer, an instructor, a consultant, and a coach. He helps developers and teams to work better and more effectively, and to develop better software. He focuses mostly on facilitating the cooperation with business, refactoring, and improving work efficiency.

Łukasz Korczyński - Experienced JEE developer, cooperating with the Nordea Group since 2011. Admirer of technology, Software Craftmanship and agility.