Tag: static analysis

Recently I had the pleasure of speaking at QAI QUEST 2016, which showcases the latest techniques for software quality measurement and testing. It was a content-rich program with more than three days of diving deep into issues like DevOps, Open Source, Security Mobile and more. But what struck me the most above all the event chatter is that even the brightest of companies are still having a difficult time identifying and fixing code quality errors.

Software risks to the business, specifically Application Resiliency, headline a recent executive roundtable hosted by CAST and sponsored by IBM Italy, ZeroUno and the Boston Consulting Group.  European IT executives from the financial services industry assembled to debate the importance of mitigating software risks to their business.

Over the past decade, advancements in static analysis tools from both commercial and open source communities have dramatically improved the detection of developer violations of good coding practices. The ability to detect these issues in coding practices provides the promise of better software quality.

The ever-growing cost to maintain systems continues to crush IT organizations, robbing their ability to fund innovation while increasing risks across the organization. The cost of maintaining a software system is directly proportional to the size and complexity of the system. Therefore any effort to reduce the size and complexity translates into direct improvement of software maintenance costs. The following provides guidance on how a static code analysis of applications generates actionable insight you can take to immediately improve the maintainability of systems.

As the product manager for CAST Highlight, it’s refreshing to see a shift in discussions about the “quality of cloud solutions” to “cloud quality solutions.” Recently, there have been an increasing number of cloud-based static code quality analysis tools, or should I say services. A few that I’ve been watching include:

Most organizations have started to realize that code quality is an important root cause to many of their issues, whether it’s incident levels or time to value. The growing complexity of development environments in IT -- the outsourcing, the required velocity, the introduction of Agile -- have all raised the issue about code quality, sometimes to an executive level.

Business applications have always been complex. You can go back to the 70s, even the 60s, and hear about systems that have millions of lines of code. But here’s the rub: In those days it was millions of lines of COBOL or some other language. But it was all one language. All one system. All one single application in a nice, neat, tidy package.

Over the past 10 years or so, it has been interesting to watch the metaphor of Technical Debt grow and evolve.  Like most topics or issues in software development, there aren’t many concepts or practices that are fully embraced by the industry without some debate or controversy.  Regardless of your personal thoughts on the topic, you must admit that the concept of Technical Debt seems to resonate strongly outside of development teams and has fueled the imagination of others to expound on the concept and include additional areas such as design debt or other metaphors.  There are now a spate of resources dedicated to the topic including the industry aggregation site: