SCA in an Agile World | June 2010

Source Code Analysis in an Agile WorldTodd Landry – Senior Product Manager

About Me13+ years in Product ManagementKlocwork PM for 2+ yearsWorked with multiple Agile teamsCertified Scrum Product OwnerContact Info:EMAIL: todd.landry@klocwork.comTWITTER: http://twitter.com/todd_landryBLOG: http://www.klocwork.com/blog

Before We Get Started Not a sales pitchIntended as an educational sessionProvides a high level overview of Agile and Static Code analysisUnderstand how they can work together

Agenda Agile OverviewIntroducing Static Code Analysis Adopting tools into AgileHow Klocwork Fits in AgileSummaryQuestions

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.

Who Uses Agile?Software organizations everywhereAerospace: Raytheon, Northrup GrummanAutomotive: GM, DaimlerChryslerBanking: Merrill Lynch & Co., T. Rowe Price GroupCommunications: Verizon Wireless, SBC...

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

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 aboveSo what is Agile development?

Introduction To AgileAgile first surfaced in mid-1990’sReaction to waterfall development Bureaucratic, slow, and inconsistent with the ways that software developers actually perform effective workDifferent ‘types’ of AgileScrumXPFeature driven developmentLean developmentAdaptive Software DevelopmentDynamic Systems Development Method (DSDM)Kanban

SCA in an Agile World | June 2010

Agile Manifesto SummarizedAgile development is an approachContinuous and rapid delivery of working softwareEmbrace changeCollaboration and communicationAll about the TeamSimplicity

Agile vs. WaterfallWaterfall DevelopmentAgile DevelopmentVerificationImplementationMaintenanceDesignRequirementsx months/years2-4 weeks

Typical Agile Process24 h2-4 WeeksProduct BacklogIteration BacklogIterationWorking Increment of the software

The IterationVerificationImplementation/DevelopmentDesignDeployment/Maintenance

What Happens with Bugs in Agile?During the iteration, bug fixes are addressed before any new feature/task is startedAt the end of an iteration, any outstanding bugs typically go to the top of the list for the next iterationNew features are not started until all bugs are fixedSchedule starts to slipMorale can declineBACKLOGAwesome Feature 1Cool Feature 2Cool Feature 3

Introduction toSource Code Analysis

Source Code Analysis (SCA) – The BasicsWhat 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 defectsSecurity vulnerabilitiesArchitecture validityConcurrency violations and rare boundary conditions Software metrics generation and managementDistinct from more traditional dynamic analysis techniques, such as unit or penetration testsUnderlying technology is called static analysisWork is performed at build time using only the source code of the program or moduleComplete view of every possible execution path, rather than an aspect of observed runtime behaviorConfidential

SCA – A History Lesson1st Generation SCA2nd Generation SCA3rd Generation SCA1970’s2000Today

Source Code Analysis - Historical perspectiveLint was invented as a developer’s toolLots of problems with the modelNoise, inaccuracies, too-small a locality of referenceBut 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, initiallyLooking for “known aberrant” problems with CMissing / extra semi-colonsMissing curlicuesPotentially dangerous implicit casts

Source Code Analysis - Historical perspective2nd 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 pathsEstimating the values that variables will assumeSimulating potential runtime behaviorMoved away from being a developer toolIn order to produce good analysis, must do it at integration buildSo it’s not part of the developer’s workflow, it’s asynchronousSo when a bug is found it’s too lateThe developer is already on some other task and must be dragged back

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

The Costs of Bug Containment2nd Generation Source Code AnalysisConfidential

3rd Generation Source Code AnalysisDeliver 2nd generation analysis capabilities right to the developer desktopFocus on enabling the developer, not blaming themIf the tool is “mine” I’m more likely to use it when I’m in processIf I use it in process, I’ll find and understand the bugs more quicklyIf I understand the bugs, I’ll fix them fasterIf I fix the bugs, the code stream isn’t polluted, my QA time isn’t wasted, and my product gets betterBottom lineDon’t check in code that doesn’t work!Build defensive coding into the organization from the ground upNarrow the gap between the rock stars and the internsMake a better product

The Costs of Bug Containment3rd Generation Source Code Analysis2nd Generation Source Code AnalysisConfidential

The Iteration with SCAVerificationImplementation/DevelopmentDesignDeployment/Maintenance

Agile team membersDevelopers have their feet under the table nowProvide input on what’s being doneDetermine whether it makes senseAgile tools tend to cater to the process of teamingProduct manager toolsProject manager toolsTime management toolsCustomer relationship toolsSo where do we come in?None of these tools are targeted at the developer

There are very few developer tools…Continuous integrationOK, but is that all there is?CI helps out with the production processWhere are the tools for actual development?Some IDEs / languages are awesomeJava, Ruby, Python, all great productive languagesC/C++, not so muchAgile isn’t just web pages and prototypesMission critical applications are being developed using Agile nowAnd they use those unpleasant languages.

Agile developer tools?We all know that Agile isn’t about tools, we’ve all read itFirst 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 sustainabilityRefactoring supportOrganic peer review

Klocwork Agile Desktop Early Defect DetectionCollaborative MitigationRefactoringCode Review

Find Defects Really EarlyAgile requires a product every iterationIf you don’t hit that milestone, then you fix first, implement later in the next iterationThe worse it gets, the more bug debt you accumulateVelocity deteriorates the further into the project you getBug debt kills projectsLow velocity  Low morale  Angry (or at best skeptical) customersUntil, finally… “This process doesn’t work!”So fix early, fix oftenMaintain high quality, low bug debt, high velocity

Keep Everyone in the LoopShort iterations require rapid communicationKlocwork provides collaborative mitigation for all reported issuesDevelopers can change the status/add comments for these issuesStatus changes and added comments are automatically synchronized with other developersNo duplication of issue fixesComplex bugs can be worked on/tracked as a team

Refactoring…OK, but why?Refactoring = The process of simplifying and clarifying code without changing the program’s behaviourWell established practice in the Agile development processDevelopers do this all the time…but it’s hard to doNeed ways to do this faster, more efficientlyAnything that has a lifecycle to it needs to be created thinking of the futureIn a development team, the future frequently means different peopleMake the code you’re creating as simple to inherit as possibleSo refactor early, refactor often

RefuctoringRefuctoring 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 yourselfCommon refuctorings include:Pig Latin (for naming conventions)Treasure huntRainy day moduleDeveloper foxholeThe Waterfall Alliance

Code ReviewAlmost always part of the development process, but is:Time consumingBelittlingBoringEmbarrassing

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

Klocwork InspectSo how have we changed code reviews?Organic, bottom-up, rather than imposed, top-downPeer-based, not hierarchicalEarly and often, not after the factAsynchronous, rather than “around the table”Defects found through SCA integrated into the code reviewDon’t bring the person to the review, bring the review to the person

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

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

SummaryAgile is a development methodologyMany different flavours...Klocwork can help in all of themKlocwork provides tools for the developerFinding issues as early as possible in the SDLC eliminating costly reworkAllowing near-real time collaboration on issuesAllowing users to refactor their code for better consistencyProvide a non-intrusive process for a critical (but painful) component of software development...the code review

SCA in an Agile World | June 2010

More Related Content

What's hot (20)

Viewers also liked (8)

Similar to SCA in an Agile World | June 2010 (20)

Recently uploaded (20)

SCA in an Agile World | June 2010

Editor's Notes