IBM Podcast [ MUSIC ] GIST: Welcome to this IBM Rational podcast, enhanced development and delivery efficiency by improving initial core quality. I'm Kimberly Gist with IBM. Catching defects earlier in the development cycle increases efficiency and contributes to lowering the overall project development cost. Well, today Kathy Chan, Rational Application Developer Release Architect, and Bill Smith, Product Manager for Rational Integrated Development Environments both join us to discuss an integrated development environment that provides automated tools which can quickly create high quality code during software implementation. Kathy and Bill, welcome to the Rational Talks to You podcast series. Looking forward to our discussion today. SMITH: CHAN: Thanks, Kim. Pleasure to be here. Thanks, Kimberly. GIST: Absolutely. Why don't we get start and Bill the first question is for you. Bill, why is improving initial code quality such a necessity? -1-
SMITH: Well, Kim, I'd like to answer that from a DevOps perspective. IBM takes a very holistic view of DevOps and its challenges, looking at the lifecycle starting with first business level and then application level planning, then collaborative development and continuous testing, all tightly coordinated with continuous release and deployment. And then, continuous monitoring and optimization; and to close the loop, collection of customer feedback is inputs to the next iteration of planning. Now, we have solutions with help with each of those aspects, but that's a huge animal, isn't it? You're not going to swallow that whole thing at once. So, we articulated DevOps capability maturity model and we provide self-assessment aids to help customers understand at which of those phases their most acute pains or shortcomings manifest. And we map those to various entry points to DevOps improvement. And that points of our end to end solution to help in that phase. And the reason I mention all of that and the point I want to make is that as you assess where you need to focus, you need to be sure that you correctly understand the root cause of any pain or shortcoming that you identify. For example, perhaps you conclude that your biggest bottleneck is in the continuous testing part of the -2-
lifecycle or maybe you conclude it's in the continuous release and deployment phase. But if you think of testing, at least part of the root cause might be that your test resources are experiencing way too much churn and repetition of effort due to low initial quality of the code they're given to test. Or similarly, if you think the problem is with release and deployment, maybe your operations resources are experiencing way too much rework and repetition of effort. Again, due to low quality of what they receive on the first one or two or maybe even first 10 attempts to deliver a new application or version thereof. All of which is waste, which is the antithesis of being lean. And really, whether you view things through a lean IT lens or a DevOps lens, the things you're really striving for are the same: speed, business agility and reduction of waste -- or, in other words, leanness. And we also know this, based on many studies and real world outcomes starting at least 15 years ago or more. For example, the work of Barry Boehm and Victor Basili and their software defect reduction Top 10 list that it costs 100 times more to address a defect in production than it does to find and fix it during requirements. And it still costs at least 10 times more once a bug is in production -3-
than if you caught it during implementation. And every defect is pure waste to start with, so what you really want to do is prevent. Any time that you're wasting is time that you're not investing in innovating, in besting your competition and in better serving your customers. So, let me just state all of that much more simply: money is the reason that improving initial code quality is such a necessity. GIST: Well, great points, Bill, and it just really highlights the fact that this conversation really takes into account how to achieve speed, business agility and to eliminate that waste. So, Kathy, what would you say are the tools included with Rational Application Developer that help with improving initial code quality, then? CHAN: Well, there are a large number of well integrated tools that are included with Rational Application Developer that help with improving initial code quality. Let's look at the development cycle from the beginning. When developers first develop their application using RAD, the fact that RAD support a wide variety of wizards for different programming models, such as OSGI, web services and SCA, means that the tools will automatically generate the needed code for you, according to the programming model. -4-
This is much less error prone than writing your own code. These tools also provide content assist editor and quick fixes which automatically suggests ways to fix up problems and guide users in writing code that meets the requirement. The smart editor of various artifacts, such as the deployment description editor, the web services editor, make it even easier to generate code correctly initially rather than having to manually create or edit the resulting descriptors. So, once the initial code is written and before the code is checked in, developers can then take advantage of the software analyzer function to run static analysis on the code. User can hand select a set of predefined rules such as certain defined patterns, security, J2EE or J2SE best practices, or even write their own custom rules according to corporate guidelines. This result of the static analysis can be easily navigated. Double clicking on the specific entry will bring up the editor for the effected file and quick fixes will guide the user on how to fix up the code. After that, different report can also be generated from the analysis result. Once the user is done with statically analyzing the code, they can then automatically generate unit tests to test the -5-
application using the J unit framework. For code testing, one thing often being asked is whether the test coverage is adequate enough or not. The Java code coverage tools in red enable users to collect code coverage information while running a Java application or a J unit test case. Code coverage results are shown in the enterprise explorer view and can be shown in a report which gives aggregated result in package, file or method level. The code coverage results are also fully integrated in the Java editor. Color bars within the editor is used to clearly show where a particular line is covered by the test or not. In addition of being used as a standalone development tool, Rational Application Developer can also be installed in the same program group as Rational Team Concert. With this set up, RTC project administrators can set different delivery criteria before code being developed using RAD can be checked in. This is set criteria such as requiring code review or requiring adequate code coverage. Once these criteria are set, code that does not meet these criteria would not be allowed to be checked into RTC. This ensures that initial code quality is met even before checked -6-
in. RAD also has a code coverage extension to the RTC build system tool kit that enables user to collect code coverage statistics while running build verification test. Code coverage results from the build can then be easily downloaded to the workspace and be viewed in the source editor. As many of you know, having defects in the code is often unavoidable. If you can't always avoid them, then find and fix them as quickly as possible and sometimes that requires collaboration. When doing debugging, it's often helpful to share debugging info with another developer who is more familiar with a certain area of code. By using the team debug feature, the first developer can park a debugging session on an RTC server, right in the middle of debugging. Then another developer who have access to the RTC server, can download that debugging session and continue with debugging with full access to the breakpoints and variables the first developer had set. This team debugging feature enables developers with different expertise and different area of code to collaborate on problem determination seamlessly. Also, when running an application, users may run into a performance problem. They can then use the Java profiling tools to profile the application, to collect information such as -7-
execution analysis, memory analysis or threat analysis data in order to find and fix these performance problems. In addition to collecting profiling information on a standalone Java or Eclipse application, users can also collect profiling information or code coverage statistics on a web application running on different versions of WebSphere application servers, including the liberty profile. As you can see, all these tools in the Rational Application Developer work together to help improve the quality of the code throughout the development, testing and debugging phase of a development project. GIST: Thank you, great summary and illustration, Kathy. So Bill, my last question is for you, then. How would you say these tools and solutions are different from other tools available now in the marketplace? SMITH: Well, you know, in all honesty, each of those tools that Kathy mentioned on its own might not be all that different from other things that are available in the marketplace, although when you get down into the low level details, I'm confident that we do have a number of capabilities that are unique, but those aren't really things that we should try to get into in a 15-minute or less podcast. -8-
So, at a higher level, what really is different, I think, is the way that we've integrated all of them. For example, the way that you see code coverage information or performance hotspot information as decorations on your programming editor or your outline view or other views in the IDE and the way that we've integrated with Rational Team Concert, as Kathy described. Then, also the way that we package them. You buy one tool and you get everything you need. One thing to install and configure as opposed to, for instance, caching together your own tool stack using Eclipse and variety of third party plug ins that you integrate yourself or maybe using a commercial IDE together with separate coverage or profiling tools that maybe aren't integrated into the IDE experience at all. And you're tabbing all day long. And then on a related note, that also, that packaging, the way we do this gives you a single source of vendor support. In fact, that really is a general value proposition of Rational Application Developer that tends to be a little bit overlooked. Even from IBM, there are development tools approaches that you could take that wouldn't have that benefit. For example, for a couple of years now we've had this -9-
offering called WebSphere Development Tools for Eclipse, or WDT. It's free and its IBM supported, sort of, and I'll come back to that in a second. But what does it consist of? First of all, it doesn't contain any of the static analysis or the code coverage or profiling or team concert integration capabilities that you get with RAD that we just heard about from Kathy. Nor does it have all the same wizardry and so on that RAD provides. But moreover -- coming back to what I alluded to a second ago -- DWT is delivered as a set of plug ins in the form of a P2 update site that you apply to your own separately provisioned Eclipse. So, none of that underlying Eclipse foundation including the very crucial web tools platform is IBM supported in that configuration. Only the bits that come in the WDT update site itself are IBM supported. With RAD on the other hand, we include the complete IBM Eclipse SDK or what we call IES which is an Eclipse configuration that IBM tests, performs legal scans on and validation, we do security scans on it, we bring it up to various of our own corporate accessibility standards, our globalization standards and so on. And when the value add bits of RAD sit on top of IES, as opposed to, you know, an independently provisioned Eclipse instance, then that entire tool stack is IBM supported. -10-
Likewise, the WAS test environments that we include with RAD, those are supported under the RAD umbrella whereas if you get them separate in the form of WAS developer edition, they're unsupported unless you buy a separate support subscription for them. So, to recap and conclude, our solution with RAD is different from others based on a combination of some unique capabilities, a unique level of tools integration, a unique level of convenience and the value of single vendor support for the entire stack. GIST: Well, thank you, Kathy and Bill. A great review of our RAD solution and how IBM is making some key advances in the integrated development environment or IDE space. We sincerely appreciate you taking the time to join us and share expertise today. SMITH: CHAN: Well, Kim, thank you, it's been our pleasure. Thanks, Kim. GIST: That was Kathy Chan, Rational Application Developer Release Architect, and Bill Smith, product manager for Rational Integrated Development Environment with some key points and great summaries for today's podcast topic, enhanced development and delivery efficiency by improving initial code quality. -11-
To hear this specific podcast or to browse additional topics, check out our Rational Talks to You podcast page at www.ibm.com/rational/podcast. This has been an IBM podcast. I'm your moderator Kimberly Gist. Thank you for listening and we hope that you will choose to keep tuning in as Rational Talks to You. IBM Podcast [ MUSIC ] [END OF SEGMENT] -12-