Most businesses seek competitive advantage through some kind of change. Whether they want to beat the competition to market with a new service or introduce new product categories, disruption is the norm.
The challenge in today's IT-centric world is that every one of those disruptions requires a software change, introducing the potential for downtime and lost revenue.
Change control and the associated risk mitigation is a big problem that every large organization faces. Last year, the London Stock Exchange crashed during a software change and was down for more than seven hours, costing traders millions, if not billions of dollars in lost business. This year we've had high profile outages at Salesforce.com, Twitter, and Amazon's EC2, among others, affecting tens of millions of people.
No company is immune to this type of risk and companies that want to stay on the leading edge need to embrace these changes in order to stay competitive.
Coverity, a software integrity firm perhaps best known for its SCAN project of open-source software sponsored by the Department of Homeland Security thinks it has the preventive medicine to help organizations avoid the inevitable errors, defects, and failures that software change can introduce.
The company's latest release, Coverity 5, promises to mitigate the business risk of software changes across an organization's entire software portfolio. It claims this is the first product that lets developers automatically map and identify how a single defect impacts multiple code bases, projects, and products. Through a unified defect management interface, it also can help organizations review, prioritize and triage their C/C++, Java and C# defects in a single work flow.
This approach lets an organization quickly answer five key questions of software change management:
- How do I find defects introduced by changes?
- How do I know the severity of new defects?
- How do I know the impact to my code, my projects, my products?
- How do I fix them fast?
- How do I know I fixed them?
Today, market opportunities are changing faster than businesses can deliver. When your organization changes software, how quickly can answer the five questions above?
The tech world is all too familiar with Twitter's "fail whale" and have become accustomed to Gmail failures (which are inevitably chronicled on Twitter.) And while sometimes it's infrastructure (such as routers and switches) rather than software that fails, it often seems as if we too readily accept that software will inevitably breakdown.
Mark Donsky, director of product management at Coverity, commented recently about a recent static analysis of open-source projects performed on the Scan site that showed a 71.9 percent correlation between the number of lines of code and number of defects found.
This is of course, not an open-source problem but a general issue that occurs as more code is integrated into products. I've been told that Windows is developed with two quality assurance people to every engineer as the product has grown over the years.
Coverity is focused on software integrity and advocates static analysis early in the development cycle. While testing of all kinds, including static analysis are obviously good ideas, the tools and methods vary dramatically by engineering organization. The Software Engineering Institute (SEI) at Carnegie Mellon University and the Object Management Group (OMG) recently paired up to form a consortium to establish standards for software quality.
... Read more
Last week, Google updated App Engine with support for the Java programming language, opening up another chapter in the development-stack-in-the-cloud concept.
Still the most popular programming language--if only by a margin--Java support could mean potentially more apps being built and more developers using App Engine. Does this mean developers will simply be more productive and can deploy apps that just work? Or are there hidden issues in pushing those apps into the cloud?
The latter is more likely, says Ben Chelf, CTO and co-founder of Coverity, which is set to introduce a new offering Tuesday to tackle these hidden issues. "There's a lot to consider when moving apps into the cloud. Race conditions, deadlocks, and performance problems due to poor locking decisions--these are the 21st century problems multithreaded applications face and you've got to be ready for them when you move to the cloud."
If applications aren't designed to be executed in a massively parallelized environment like the cloud provides, they could have flaws--flaws that while hidden in the comforts of your own home desktop, will be exposed to their very core when running in the cloud. A lot is going to come down to the execution of the application. Here are three areas that Chelf thinks developers need to consider to build their application right for the cloud:
- Will the application be run satisfactorily if each thread runs slowly? While your desktop machine might be screaming with processors churning at 3GHz or more, the situation up in the cloud might be different. You don't control the processor speed. You just get lots of them.
- Will the application be OK if it runs in parallel 10 ways? 100? The cloud affords you the luxury of potentially running your applications in a highly distributed environment. This means coordination between threads to ensure you don't corrupt memory as dozens of threads are simultaneously carrying out the work you've so carefully programmed them to. Is your application ready for that type of scale?
- Will the application scale? Imagine having thousands, tens of thousands, or more people pounding on your application. With the cloud, now you are not limited by hardware as much anymore, but will the performance of the app you've developed handle that type of usage scale?
When we talk about what can go wrong with cloud computing today, we typically blame cloud service providers and their uptime, infrastructure, and scaling capabilities. What if the app just wasn't built for the cloud to begin with?
Follow me on Twitter @daveofdoom
- prev
- 1
- next
