Category: Risk & Security

I’ve been asked time and again how CAST is different from performance engineering. And here’s my answer: The CAST discipline of software analysis and measurement versus performance engineering couldn’t be more different. And I’ll explain why and how in a moment. But along with that, it should be noted that they also are like peanut butter and chocolate -- they can go very well together.

Risk detection is about identifying any threat that can negatively and severely impact the behavior of applications in operations, as well as the application maintenance and development activity. Then, risk assessment is about conveying the result of the detection through easy-to-grasp pieces of information. Part of this activity is about highlighting what it is you’re seeing while summarizing a plethora of information. But as soon as we utter the word "summarizing," we risk losing some important context.

Risk detection is the most valid justification to the Software Analysis and Measurement activity: identify any threat that can negatively and severely impact the behavior of applications in operations as well as the application maintenance and development activity.

My six-year-old can tie her own shoes. I honestly did not realize how big of a deal that was until her teacher told me a few months ago that she had, for a short time, become the designated shoe tier in her classroom. Apparently, thanks to the advent of Velcro closures for kids’ shoes, nobody else in her kindergarten class knew how to tie their shoes.

Any advocate for better software quality knows that one of the biggest challenges is helping the CIO reach the CFO. When your team needs a budget for an important project, those conversations often break down. Thanks to the unavoidable technical complexity of IT, oftentimes the CIO might as well be speaking Esperanto to the CFO.

We all know testing is an essential step in the application development process. But sometimes testing can feel like your team is just throwing bricks against a wall and seeing when the wall breaks. Wouldn’t it make more sense to be measuring the integrity of the wall itself before chucking things at it?

I’m not one who believes in fortune tellers or those who claim to be able to predict the future. Heck, I don’t even read my horoscope and cringe whenever someone attempts to force it upon me. Only when my wife has attempted to read me my horoscope have I offered even as much as a polite “hmm.” Nevertheless there are many out there who swear by those who claim to be able to predict the future, especially in the financial industry.

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:

Every year, Senator Tom Coburn compiles the Wastebook – A Guide to Some of the Most Wasteful and Low Priority Government Spending of 2011.