Dr. Andreas Kuehlmann
Senior Vice President of Research and Development
Coverity
Challenges in technology to meet enterprise needs in 2013 and expectations
"Doing more with less" sounds like an overused term, but I think it characterizes the challenge that many organizations face today. Especially in software, where continuous deployment and dramatic market pressures have led to rapid product delivery cycles where the need for speed often outweighs the value of product quality and security. It is tempting to defer solving fundamental issues that have a less immediate value to later, which often leads to a rapid growth of technical debt. The key is to stay in the “driver’s seat” and constantly balance the short-term value of product feature delivery with the long-term liability to efficiently expand and maintain the product. Modern development tools and methodologies, precise metrics to gauge progress and quality as well as good coordination between all stake-holders are critical for succeeding in this.
The areas in business environment where solutions do not yet exist or not up to the mark, and which if existed, would've made job easier
I spent a significant part of my career working on tools and processes for hardware verification, for example at IBM for microprocessors. Our practical experience seems to suggest that hardware has fewer bugs than software - if your PC crashes, are you more suspicious of Intel's or Microsoft's technology? In my opinion, software verification is not fundamentally different from hardware verification. But due to the cost structure and historical business needs, the state-of-the-art for hardware verification seems 10-15 years ahead of that for software. Meanwhile, the business drivers have changed dramatically and I foresee that software will catch up quickly in terms of tools and processes. This will take a while but as our experience in hardware suggests, there is no "single bullet" solution. Getting large systems right requires a combination of different verification approaches and a highly disciplined development methodology around them. These are exciting times, providing opportunities for innovation and significant differentiation.
Technology Trends Impacting Enterprise Business Environment
In the past, the industry has focused on improving the mechanical part of software development. The trend of agile processes, better tools for source code repositories, bug tracking, project/scrum planning, build systems, etc., as well as their better integration, has led to a significant improvement in the quality and efficiency of the software development process and made it scalable for larger organizations. Moving forward, I see a trend to make processes smarter by adding "brains" to the tools, with the goal to focus expensive human efforts on what is most important. For example, static code analysis was a big step in our ability to easily find software bugs that are hard to identify with traditional testing and make their elimination part of the daily development process. At Coverity, our own experience utilizing the "code intelligence" offered by deep static analysis for steering other processes shows significant promise for improving development efficiency, reliability and quality. For example, we started using code intelligence to focus our development testing on parts of the software code that really matter, and began prioritizing the execution of tests on the ones that are relevant for code updates. Based on this experience, we integrated this functionality into a new product which we launched last fall and which shows significant traction with our customers. I see many more opportunities to apply code intelligence for improving tools and processes.
My roles and responsibilities as a CIO
Almost every company is now - to some degree - a software company. More product functionality, customer data crunching, operational optimizations, an open "apps" infrastructure reflecting customization capabilities combined with an ecosystem for others to participate...and the list goes on. With the increased value of software for the core business comes higher vulnerabilities to quality and security. The tolerance of quality problems – which are the equivalent of the "blue screen of death" - is long gone, as they can severely impact business operations. Similarly, security exploits can have catastrophic consequences for a company brand, as well as its financial liability. All these trends raise the stakes for the CIO; his or her operation is moving from a "back-office" side show to a key business differentiator. We are observing this trend with many of our customers; they are paying significantly more attention to software quality and security, utilizing modern technology and driving a change of behaviour within their operations.
Lessons learnt and your advice for fellow CIOs
Three things come to my mind: people, metrics and automation. First, hiring the right people makes a big difference. This is sometimes hard when an operation needs to be ramped up quickly and the CFO threatens to have the budget expire in the next fiscal quarter. However, in my experience, waiting for the right person always pays off. Also (and contradicting the general business trend), we try to minimize distributed teams. At Coverity, we used to have a distributed QA operation in Eastern Europe; however we consolidated this activity and moved it to Calgary, Canada. For us, the smaller time difference, the "reachability" by a two to three hour flight and the lack of a language barrier paid off.
Second, as with any business, good metrics are key to steer processes and organizational behaviour. Without metrics, we fly blind and get caught by surprises that require fire-fighting including significant overtime and weekend shifts. This is tricky for software development as we cannot directly measure the advancement of the development process and the quality of the code in the same way as other areas - e.g. for gasoline by measuring its amount and chemically analyzing its components. Agile development helps a lot to gauge the progress of development. However, it is critical to interleave the testing effort to ensure that features are truly completed before being accepted. Otherwise, we can easily fool ourselves by declaring that features as done without proper testing.
This leads to a third experience: automation. Manual testing - except for a few hard-to-test areas - should be a thing of the past. Computers are very good at reliably executing mundane and repetitive tasks such as testing. Automated tests are good for two purposes: they encode the specified behaviour of a feature in an independent manner - executing the test validates that the code indeed implements that behaviour. Moreover, they provide an efficient means to catch regressions during development by identifying when a feature is unintentionally affected by other feature work. Automating testing requires a sustained investment and and a cultural shift in the development organization. I view the lack of automated tests as form of technical debt, similar to a "sauerkraut-like"software architecture of bad code quality.
