System Level Analysis Keeps Coca-Cola Smiling Webinar Recap

Michael Furniss, Director of Software Quality Assurance and Testing COE at Coca-Cola’s Bottling Investment Group lead a discussion on how system level analysis improves dialog with application service providers. He shared his experience about how software analysis and measurement has enhanced his traditional process and tool landscape; leading to better identification of legacy SAP code vulnerabilities that can lead to performance and stability issues.  Mr. Furniss outlined how Coca Cola has deployed this solution across their global organization and how it focuses development efforts to reduce risk and total ownership cost while keeping their executive sponsors and partners happy.
Want to hear the Coca-Cola Webinar: Listen Now!!
If you would like to hear more from Coca-Cola watch this video: https://www.youtube.com/watch?v=gTg4IdO0o78

6 Hidden Costs of Maintaining an Open Source Code Analyzer Platform

So, you’re ready to get started on building your own multi-language custom source code analyzer platform using open source components.  Your return estimates are still looking pretty good, even after taking into account the costs in our previous post, “6 Hidden Costs of Building Your Own Multi-Language Code Analyzer Platform”.
Well, we have a quick list of maintenance costs that you may not have considered.  So, before you break ground on that project, see if you thought of all these.

6 Hidden Costs of Building Your Own Open Source Code Analyzer Platform

Thinking about building your own multi-language custom source code analyzer platform using open source components?  Sure, the upsides seem to add up: no licensing fees, great customization ability, and an impressive new entry on your resume (making it even shinier).  Read that project charter once more before you sign it in ink, because our experience has shown it’s not quite that simple.
Source Code Analyzer:  What is under the code?
First, what we mean by “multi-language custom source code analyzer platform” is a platform that analyzes all the source code underlying your critical custom software applications and projects, and:

Delivers consistent and business relevant measurements, trends, and benchmarking
Enables staff to identify and address flaws causing instability and excess complexity
Provides insights on the trajectory of code quality and complexity
Analyzes flaws at both the code and component interaction levels across all technology layers

Anything less would leave your applications difficult to manage, your users unsatisfied, and your management team in the dark.

A Gold Watch Salute for Technical Debt

Talented IT teams regularly beat themselves up over technical debt and have built comprehensive plans to effectively manage and minimize its effects. Prodded by Larry Dignan in a recent post, just for today, take a break and instead look at the technical debt practices of enterprise software vendors.
You would think that with their huge teams, the large enterprise vendors would have wrestled technical debt to the ground a long time ago. You would be wrong.
There are several reasons why large software vendors often have technical debt issues as severe or worse than their small vendor/application counterparts. Among these:

Some of the companies are public and must continuously roll out new versions and features that goose revenues and profits to keep shareholders happy.
Others have been or are about to be acquired, and programmers are laid off to make the numbers look better, which causes the company to lose legacy knowledge as well as the programming skills to address technical debt.
Still others are in fierce competitive wars with other vendors and know that shiny new features sell, and assume they can get to addressing technical debt later.

Yet the technical debt buried within these applications can be a ticking time bomb. The more debt in place, the less likely you, as part of an IT team, will receive those amazing benefits the enterprise software vendor promised. Technical debt is one reason why being a late adopter isn’t always the best move: you get the downside of the accumulated technical debt, without the upside of the initial software innovation.
Another concern about technical debt inside enterprise software is the drag on the vendor’s future innovation. As technical debt increases, it reduces software quality and functionality, and forces the enterprise development team to focus resources on fixing the debt, which translates to higher prices.

How Did We Get Here?
Much enterprise software was designed in a different era, when it ran on mainframes, developers didn’t have to think about mobile apps, people working remotely and running it on today’s much smaller servers.  Software viruses were few and far between.  Competition came from a few, easily identifiable vendors.  And, much of the software was built on traditional code, such as COBOL.  The attitude of software designers was to build in every feature imaginable and let users decide what they want.
Today, much of the code developed in that early era is still recognizable. If you examine the guts of today’s enterprise software, you can often recognize that “kitchen sink” mentality.  If you are considering the purchase or subscription of “new” enterprise software, it would pay to look under the hood of how that code was constructed.
Ways to Identify Technical Debt
To identify serious technical debt issues in the design of the software (finding technical coding debt is much more tricky), here are three questions to ask the vendor:

Is the software built on a contemporary object model?  Ask them for a review of their major object classes and how they are related.  If you don’t have the knowledge, make sure you have someone with you who thoroughly understands object models.  If  all the vendor shows you is the physical design of relational database tables, you may be looking at very old thinking and programming.
Is the software systematically effective-dated?
Are all the business rules that drive the software abstracted to effective-dated metadata?  Can their metadata be configured non-destructively?  Are there any business rules expressed as application code?

To be fair, any enterprise vendor who has been in business for more than a few years will have some technical debt.  You should ask how quickly and effectively their team is working to manage and minimize technical debt.
While it’s somewhat comforting to know that even huge software vendors struggle with technical debt, it’s critical that you get a handle on their technical debt issues as part of your strategy to handle your own.