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.
It’s simple physics: a piece of application code gets caught in a logic loop, the CPU heats up as the increased throughput tries to make sense of the commands, the computer reacts by pumping more power to the motherboard and cooling system to keep everything up and running, and your electricity bill goes up.
For a household server, this increase might be a miniscule blip in your monthly bill. But for a large IT organization with hundreds of thousands of servers located in datacenters around the world, that could start eating into quarterly profits.
Despite mounting evidence that the use of fossil fuels will damage our environment, humanity appears hard pressed to find an alternative. And even though environmentally friendly options have presented themselves, we have one foot firmly planted in the past. Working in the IT industry, it’s astounding how closely this resembles our current state of agile software development and testing.
Even though the industry identifies that a problem exists, and have the tools available to fix it, its dead set on sticking to “the way it was.”
Our colleague Vijay Anand recently penned an article exploring this topic and outlining what software development teams can do to maintain their current level of production, without sacrificing software quality. Read the full story HERE!
Last Thursday we had a fascinating discussion with Suresh Bala, the head of Application Management at Wipro, Diego LoGiudice of Forrester, and Dr. Bill Curtis, the Director of the Consortium for IT Software Quality. Diego presented the latest trends in IT organizations in reference to splitting their activities and applications into systems of engagement and systems of record. This has been the Forrester view on IT, or what they call Business Technology (BT), for some time now. The systems of engagement being the fast-moving, often mobile-based, applications that are meant to disrupt competition and engage the customer in new ways. The systems of record being the traditional backbone IT systems that manage the core enterprise data and business processes.
Suresh Bala described how Wipro closely manages the software product in order to improve short- and mid-term agility on behalf of their clients. Suresh described an impressive system of tools that underlie their own Agile processes, while proactively managing technical debt. He also presented a pretty advanced scorecard, called AppInsight that they use in order to track how the applications under Wipro management are doing from a health and robustness standpoint.
Then, Bill Curtis took us to the conclusion by describing the metrics being standardized by CISQ, and how these measures can be used to manage the evolution of software, and to provide standard terms for software quality in application services contracts.