In the Bible, when Moses returns to Mount Sinai after smashing the Ten Commandments, God says to him, “The LORD, the LORD, the compassionate and gracious God, slow to anger, abounding in love and faithfulness, maintaining love to thousands, and forgiving wickedness, rebellion and sin. Yet he does not leave the guilty unpunished; he punishes the children and their children for the sin of the parents to the third and fourth generation.”
God may have been talking about the Israelites, but it also sounds like he’s talking about software development.
When code is first written, many of its flaws or “sins” are not immediately apparent and transgressions are, if you will, “forgiven”, enabling the application software to run smoothly. Often it is not until the code is being reused for a third or fourth generation that the issues lying within it are betrayed and the “children and their children” of that original code “parent” pay the price in the form of a system outage or security breach.
Recently, Benjamin Day, a consultant and trainer specializing in software development best practices, penned a contributed piece for Redmond Developer News in which he discussed a frequent problem he has been witnessing in one type of software development – the rewrite. He says:
The organization has an existing application and, for whatever reason, the development team is tasked with re-writing it. The project starts out okay but somehow it starts to go off the rails. No one knows when it's going to be done. There's a massive amount of technical debt – a.k.a. work that's not completely done – and people are starting to worry about the budget.
Day blames morass of technical debt and budget overruns on what he calls “development hubris", which he explains occurs when “Teams think that they have the requirements nailed. They feel that they don't face as much risk and uncertainty. As a result, process discipline – how well they're doing Scrum – suffers.”
His solution to development hubris and ultimately the rewrite quagmire that ensues is to treat every project, even rewrites, as though the team were writing a new application.
That’s not a bad solution…if the original purpose for rewriting the application was not predicated on speeding an update to market. Building a new application takes time; time that most development teams – and Scrum teams in particular – are not granted.
A much more efficient task is to begin by uncovering the potential pitfalls of the original application that is being rewritten. There are great efficiencies to be gained by obtaining insight into what the base application affords and where the issues are based on current software norms and standards as opposed to those that existed when the original application was developed.
The problem is that unless there are team members who worked on the original code, there may be no team or even one single developer who fully understands what went into that application. And even if there are team members with sufficient longevity and experience, to try and detect lines that may now cause an outage is nearly impossible. Considering that there could be up to 100 lines of code within the average 400K line application, it’s worse odds (a 0.025% chance) than trying to find a needle in a haystack.
The best way to dig out these issues and ensure the rewrite can develop in fixes for them is to perform automated analysis and measurement of the pre-existing application software. By performing this static analysis, a development team will have insight into those parts of the code that could cause system failures or leave a system open to attack by hackers or cyber-terrorists.
Automated analysis sees the whole application, going beyond one developer’s view of it. Furthermore, automated measurement of that analysis provides management the means to track, incentivize and ensure that code quality is built into the software. In other words, automated analysis and measurement can provide the insight that enables a team to take good software and make it better.
There are now platforms and services out there that can accomplish this assessment for pennies per line of code. It makes sense, therefore, that more companies looking to rewrite existing applications should perform this quick due diligence before embarking on a rewrite project lest “the sins of the father be visited upon the son.”
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.