Most IT organizations wouldn’t consider the software risk in their application portfolio a brand issue; that is, until they experience a tragedy or crisis such as application failure and customers start to worry. Most of the time IT organizations are able to calculate the cost to fix the problem and how it will affect their overall business. However, what often isn’t taken into account is the long term effects on their brand and business going forward.
For instance, it’s been an incredibly difficult year for Malaysia Airlines, who are now struggling with a record decline in passengers and preparing to restructure after losing two aircraft in the span of five months. To be fair, Malaysia Airlines had little control over the tragedies that confronted them — unlike some other crisis this year. I’m of course referring to the myriad headline-grabbing glitches and crashes we’ve seen from organizations such as Target, Facebook, American Airlines, Twitter, and Ebay. You can read more about the fallout from these bugs in an infographic we’ve compiled below.
You’d think that after news of the Heartbleed bug broke, every IT organization worth their salt would have immediately moved to start monitoring their structural robustness and code quality to protect their sensitive consumer data. And while many did, two months after Heartbleed was announced, more than 300,000 servers were still vulnerable.
Now, three months later, CAST Research Labs has found there is a direct link between the growing number of data breaches and security incidents, and poor code quality in consumer applications.
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.
The current state of measuring the environmental impact of our IT infrastructure is missing a big piece of the puzzle. One of the metrics we use, power usage effectiveness (PUE), only looks at how much power entering a data center is being consumed by the computer hardware in relation to the total amount of energy the facility uses.
But what about the millions of lines of code running on that hardware? How can we know if that’s energy efficient code?
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.
Just like a species of insects can become resistant to a certain type of pesticide, a new strain of software bugs has emerged and is plaguing software developers and wreaking havoc on software quality — architecturally complex violations. Unlike a code-level bug, a system level defect involves interactions between several components, often spread across different levels of an application, making them much more difficult to find and fix.
And even though these types of violations only account for 10 percent of the total number of defects, they lead to ninety percent of the production issues — severely impacting software quality and technical debt.
When one of our writers, Lev Lesokhin, started contributing to Wall Street & Technology he was shocked to find very little on the subject of technical debt. Considering how much the concept intersects the worlds of finance and technology, he thought he’d find whole forums of IT guys and financiers exploring the intricacies en mass.
When he realized that was far from the case, he set out to create a guide to bridge the gap and get the conversation started. By taking some of the more complex concepts of technical debt and translating them into financial language, he hoped to bring the technical jargon out of the CIO boardroom and decipher it for a financial audience.