Re-factoring – for Sr. Managers

In every industry there is a holy grail of software that no one wants to touch. It works they claim. Does not matter how archaic the architecture or programming language used is, it is too important and too many things can go wrong if you even go near it – so they don’t touch it. These could be some large volumes of assembly code running on a main frame or COBOL. People have built their careers on this code. It’s their legacy. Then one day, you can’t find them anymore. They are gone. You can’t find anyone who still knows this stuff. You are willing to pay a premium to train people to learn it and maintain it. Nothing gets done quickly by this team. They say they have limitations. No one can challenge them. No one knows.

Get rid of it! Yes, easier said than done but if you are a serious senior manager or chief architect, you must have a plan to systematically and persistently attack the beast and get rid of it. This takes guts – at the end of it all, you have nothing new to show. Not a single feature added – and if things go wrong, you would have perhaps destroyed a company. Comfy?

Of course not. You shouldn’t be. But trust me, if it was done decades ago, it can now be re-done. It can be re-done to be faster, more secure, more available and more fancy. You just have to step back and plan thoroughly and stay personally engaged more so than on other projects. Here are the steps:

1. Grasp its worth: Often the development team is insulated from what – in numbers – the product or project they are attempting to refactor is producing for their company and its customers. The team that’s undertaking the refactoring must clearly understand the product’s worth. I am yet to see refactoring as a requirement in a customer document. Customers want functional features, performance, availability etc. They want their new money to give them new things. Hardware end-of-life is something that customers have been trained to understand, albeit painfully. However, the notion that software also has an end-of-life is a concept that’s not sunk in and so not asked for and more importantly not funded. Before a development team can arrive at a decision to refactor, the team must tap into internal customer channels and product-management, finance and procurement channels to clearly understand the worth of the project. What is the revenue from the project? What are the cost structures of the product? What are the partnership and third-party vendor agreements that apply to the project/product? Be clear on the product’s worth so that you can direct technical and managerial resources appropriately.

2. Gain consensus: Refactoring is absolutely not an internal project. Even if the presentation layers and the interfaces are intact and all changes are seemingly contained, gaining consensus from upstream and downstream teams is critically important. All of these teams will have new costs. An independent black-box test team will have to plan for massive regression tests. An upstream customer team absolutely has the right to know and the right to be concerned. Often several use cases in a product are used by customers in  a very different manner than the requirements team or the development team had intended. Refactoring could impact such unintended but nevertheless useful behavior. Accepting a massive change to how things worked might not be within the customer’s risk tolerance at the given point in time. Even if the product performs better after refactoring, say in response times, that could create new issues for tools and other scripts the customer may have created around the product. Candid discussions with both upstream and downstream teams are essential.

3. Staff appropriately: The team that owned the legacy component is not automatically suited for refactoring. Technical skill gaps may be apparent. For instance if you are removing a giant COBOL core and using core Java or removing XView user interfaces and creating HTML5/Java front-ends, you need people with those new language and technology skills. What’s more subtle are abilities to massively create new code vs. ability to add delta behavior; ability to repair vs. replace; ability to work with global teams and cultures; ability to point test vs. regression test. Refactoring will require very different abilities than feature creation. Technical, process and behavior gaps must be closed. This is not only done by using new resources but also by action based on-the-job training and assignment of tasks and mentors. Agile’s paired-programming concept can be used effectively to pair a person who knows the functionality with one who knows the language – both learn from each other.

4. Right Source: Refactoring often requires massive new code creation. This would be “easy code” but would have to be written nevertheless. Identify efficient global centers to execute this well defined, contained activity. Not all offshore centers are the same. Hyderabad has different challenges than Bangalore; Hangzhou has different strengths than Shanghai. Understand different work-cultures. Plan for travel, both for your technical leads and for the offsite development team to visit the US. Plan to work with HR on limitations of various visa types.

5. Define the development environment: This is extremely important. It should address multi-language needs, multi-site needs, allow for Agile functions such as paired programming, constant integration, nightly builds, automated regression tests and automated validation. Note that in a 24 hour work mode with global teams, “nightly builds” per se needs to be defined. It will need a good source code configuration management team. Then comes labs and tools: build tools, automation tools, auto-validation tools, configuration management tools, process audit tools, development tools, performance measurement tools, debugging tools. Lab location is a significant decision while refactoring. It is best to have a co-located black box test lab for efficient communication and fast turnaround, but system integration and system test labs may have to be remote as those often involve large asset costs in creation.

6. Create the development plan: Prioritize the use cases, assess the risks and allocate risks to constructions appropriately. Prioritization is often easier with refactoring than new development as real customer usage and value stats should be available. You are not guessing what’s critical to the customer; you know it. Drop unused features. Manage the Q&A to customer channels and feed responses into construction planning. Identify “make vs buy” components. Just because it was made before, you don’t need to make it again. With correct layering you’ll often find that several components can be purchased off-the-shelf. That leads into third party selection and outsourcing criteria. You’ll have to work with procurement and often work within validated third parties. Procurement teams will have lead times, especially if they need to create new channels, establish NDAs, create overall contracts, deal with export regulations and HR rules.

7. Oversee the elaboration activity: Review the end-to-end ecosystem architecture. Oversee refinement of use cases and allocation of refined use cases to construction. Adjust construction plan as needed. Communicate to stakeholders.

8. Construction kickoff: Kickoff construction and oversee construction activities till an executable elaboration product is created. Plan to get an independent test team verify the elaboration product. This will dry-run your new release build methods, installation methods, test-readiness-reviews etc. You will discover if the new architecture successfully executes on the target platform.

Even as a senior manager or chief architect plan to be hands-on and even participate in daily standup meetings until at least the end of the first construction cycle or iteration. After that you should be able to let your staff take over and just monitor the program along with your other programs.


Leave a Reply