Check out this slideshow from Klocwork to learn more about SCA (Static Code Analysis) and Agile development.

1. Source Code Analysis in an Agile World Todd Landry – Senior Product Manager

2. About Me 13+ years in Product Management Klocwork PM for 2+ years Worked with multiple Agile teams Certified Scrum Product Owner Contact Info: EMAIL: todd.landry@klocwork.com TWITTER: http://twitter.com/todd_landry BLOG: http://www.klocwork.com/blog

3. Before We Get Started Not a sales pitch Intended as an educational session Provides a high level overview of Agile and Static Code analysis Understand how they can work together

4. Agenda Agile Overview Introducing Static Code Analysis Adopting tools into Agile How Klocwork Fits in Agile Summary Questions

5. Agile Adoption Has Reached Mainstream Proportions “Please select the methodology that most closely reflects the development process you are currently using.” (select only one) Source: Forrester/Dr. Dobb’s Global Developer Technographics® Survey, Q3 2009 | Forrester Research, Inc.

6. Who Uses Agile? Software organizations everywhere Aerospace: Raytheon, Northrup Grumman Automotive: GM, DaimlerChrysler Banking: Merrill Lynch & Co., T. Rowe Price Group Communications: Verizon Wireless, SBC ...

7. Why Agile? What’s Wrong With Waterfall ? Nothing really, still the most widely used development methodology today Most predictable of all methods...you know (for the most part), what you’re getting and approximately when Well documented set of requirements (and most everything else) Structured approach (not chaos like those Agile-guys) However, there are drawbacks Commitments are made early on, and are difficult and costly to change Not always sure you will meet the market needs at release time Risk is pushed to the end of the development period during testing phases Hard to react to problems when so late in the development process

8. Why Agile? Visibility - stakeholder collaboration and validation throughout the development life-cycle Value - continuous delivery of much more measurable business value Adaptability - the ability to rapidly respond to changes in strategy, priorities, and plans Risk - the reduction in aggregate project risk as a result of #1-3 above So what is Agile development?

9. Introduction To Agile Agile first surfaced in mid-1990’s Reaction to waterfall development Bureaucratic, slow, and inconsistent with the ways that software developers actually perform effective work Different ‘types’ of Agile Scrum XP Feature driven development Lean development Adaptive Software Development Dynamic Systems Development Method (DSDM) Kanban

11. Agile Manifesto Summarized Agile development is an approach Continuous and rapid delivery of working software Embrace change Collaboration and communication All about the Team Simplicity

12. Agile vs. Waterfall Waterfall Development Agile Development Verification Implementation Maintenance Design Requirements x months/years 2-4 weeks

13. Typical Agile Process 24 h 2-4 Weeks Product Backlog Iteration Backlog Iteration Working Increment of the software

14. The Iteration Verification Implementation/ Development Design Deployment/ Maintenance

15. What Happens with Bugs in Agile? During the iteration, bug fixes are addressed before any new feature/task is started At the end of an iteration, any outstanding bugs typically go to the top of the list for the next iteration New features are not started until all bugs are fixed Schedule starts to slip Morale can decline BACKLOG Awesome Feature 1 Cool Feature 2 Cool Feature 3

17. Introduction toSource Code Analysis

18. Source Code Analysis (SCA) – The Basics What is source code analysis? The analysis of computer software (source code) that is performed without actually executing programs built from that software. Automated code analysis technology finds weaknesses in source code Logic errors and implementation defects Security vulnerabilities Architecture validity Concurrency violations and rare boundary conditions Software metrics generation and management Distinct from more traditional dynamic analysis techniques, such as unit or penetration tests Underlying technology is called static analysis Work is performed at build time using only the source code of the program or module Complete view of every possible execution path, rather than an aspect of observed runtime behavior Confidential

19. SCA – A History Lesson 1st Generation SCA 2nd Generation SCA 3rd Generation SCA 1970’s 2000 Today

20. Source Code Analysis - Historical perspective Lint was invented as a developer’s tool Lots of problems with the model Noise, inaccuracies, too-small a locality of reference But it was always intended to “just give better compiler errors to the developer” Seen by developers as “opt-in” and “mine” What was Lint doing? Scanning, initially Looking for “known aberrant” problems with C Missing / extra semi-colons Missing curlicues Potentially dangerous implicit casts

21. SCA – A History Lesson 1st Generation SCA 2nd Generation SCA 3rd Generation SCA 1970’s 2000 Today

22. Source Code Analysis - Historical perspective 2nd generation static analysis provided better core analysis capabilities that extended beyond syntactical and semantic analyses to include: Sophisticated inter-procedural, control- and data-flow analysis New approaches for pruning false paths Estimating the values that variables will assume Simulating potential runtime behavior Moved away from being a developer tool In order to produce good analysis, must do it at integration build So it’s not part of the developer’s workflow, it’s asynchronous So when a bug is found it’s too late The developer is already on some other task and must be dragged back

23. What kind of bugs? Local bugs vs. inter-procedural bugs Local bugs are “easier” to find, and certainly easier to understand Picture “slapping head” Inter-procedural bugs are the big payoffs Difficult for different developers working on projects to deal with each other’s code rationally Lots of fingers in lots of pies = lots (and lots) of bugs What kinds of bugs? Resource management Pointer management (and yes, this means Java too) Security vulnerabilities (injections, overflows, naivety, stupidity, …) Concurrency

24. The Costs of Bug Containment 2nd Generation Source Code Analysis Confidential

25. SCA – A History Lesson 1st Generation SCA 2nd Generation SCA 3rd Generation SCA 1970’s 2000 Today

26. 3rd Generation Source Code Analysis Deliver 2nd generation analysis capabilities right to the developer desktop Focus on enabling the developer, not blaming them If the tool is “mine” I’m more likely to use it when I’m in process If I use it in process, I’ll find and understand the bugs more quickly If I understand the bugs, I’ll fix them faster If I fix the bugs, the code stream isn’t polluted, my QA time isn’t wasted, and my product gets better Bottom line Don’t check in code that doesn’t work! Build defensive coding into the organization from the ground up Narrow the gap between the rock stars and the interns Make a better product

27. The Costs of Bug Containment 2nd Generation Source Code Analysis Confidential

28. The Costs of Bug Containment 3rd Generation Source Code Analysis 2nd Generation Source Code Analysis Confidential

29. The Iteration with SCA Verification Implementation/ Development Design Deployment/ Maintenance

32. Adopting Tools for Agile

33. Agile team members Developers have their feet under the table now Provide input on what’s being done Determine whether it makes sense Agile tools tend to cater to the process of teaming Product manager tools Project manager tools Time management tools Customer relationship tools So where do we come in? None of these tools are targeted at the developer

34. There are very few developer tools… Continuous integration OK, but is that all there is? CI helps out with the production process Where are the tools for actual development? Some IDEs / languages are awesome Java, Ruby, Python, all great productive languages C/C++, not so much Agile isn’t just web pages and prototypes Mission critical applications are being developed using Agile now And they use those unpleasant languages.

35. Agile developer tools? We all know that Agile isn’t about tools, we’ve all read it First thing the manifesto breaks out “Individuals and interactions over processes and tools” Times have changed…so have the tools… What kind of tools could help Agile developers? Architectural coherence and sustainability Refactoring support Organic peer review

36. How Does Klocwork Help?

37. Klocwork Agile Desktop Early Defect Detection Collaborative Mitigation Refactoring Code Review

38. Find Defects Really Early Agile requires a product every iteration If you don’t hit that milestone, then you fix first, implement later in the next iteration The worse it gets, the more bug debt you accumulate Velocity deteriorates the further into the project you get Bug debt kills projects Low velocity  Low morale  Angry (or at best skeptical) customers Until, finally… “This process doesn’t work!” So fix early, fix often Maintain high quality, low bug debt, high velocity

39. Klocwork in Visual Studio

40. Keep Everyone in the Loop Short iterations require rapid communication Klocwork provides collaborative mitigation for all reported issues Developers can change the status/add comments for these issues Status changes and added comments are automatically synchronized with other developers No duplication of issue fixes Complex bugs can be worked on/tracked as a team

41. Refactoring…OK, but why? Refactoring = The process of simplifying and clarifying code without changing the program’s behaviour Well established practice in the Agile development process Developers do this all the time…but it’s hard to do Need ways to do this faster, more efficiently Anything that has a lifecycle to it needs to be created thinking of the future In a development team, the future frequently means different people Make the code you’re creating as simple to inherit as possible So refactor early, refactor often

42. Refuctoring Refuctoring is the process of taking a well designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anyone other than yourself Common refuctorings include: Pig Latin (for naming conventions) Treasure hunt Rainy day module Developer foxhole The Waterfall Alliance

43. Code Review Almost always part of the development process, but is: Time consuming Belittling Boring Embarrassing

44. Code Reviews – Mandatory “To what extent are code reviews a part of your regular release cycle?” 87% Source: A commissioned study conducted by Forrester Consulting on behalf of Klocwork, February 2010

45. Klocwork Inspect So how have we changed code reviews? Organic, bottom-up, rather than imposed, top-down Peer-based, not hierarchical Early and often, not after the fact Asynchronous, rather than “around the table” Defects found through SCA integrated into the code review Don’t bring the person to the review, bring the review to the person

46. How much can Klocwork help? Some examples... 2 week iteration & 10 person team 5 stories – 300LOC/story Real world customer ROI examples… Lawrence Livermore saved $200,000 on 365 KLOC project Motorola reduced # of issues found at System Test by 50% Mentor Graphics found 1000 bugs with no involvement from testing

47. All Good Stuff...But There needs to be a balance Tools must help develop better code, and not hinder individual interaction Tools must do the job with minimal effort, and minimal side effects Be flexible...Fit the tool to the team, not the team to the tool...otherwise you’re toast!

48. Summary Agile is a development methodology Many different flavours...Klocwork can help in all of them Klocwork provides tools for the developer Finding issues as early as possible in the SDLC eliminating costly rework Allowing near-real time collaboration on issues Allowing users to refactor their code for better consistency Provide a non-intrusive process for a critical (but painful) component of software development...the code review

49. todd.landry@klocwork.com http://twitter.com/todd_landry