 Randy Ribler – Lynchburg College  PhD from Virginia Tech  Postdoc at University of Illinois (UIUC)  Many years of industry experience building systems   I was here before in 2006  I’m absolutely delighted to be back in 2013

 Hobbs Hall

 How do we build big systems?  How do people work together best?  How can we prevent project failure?  Failure rates are debatable, but undeniably too high  How should individual programmers do their jobs?  What are “best practices”

 Fewer things are provable  Hard/Impossible to repeat anything  Every situation is a different  Projects are different  Staff is different  Tools are different  Customers are different  SE has been wrong before  Conventional wisdom has changed radically in the last several years.

 Structured Programming  Object-oriented Programming  Design Patterns  Configuration Management  Pair Programming  Test-driven Development  Refactoring  A number of software process models  Coding Standards  Tools

 Chaos!  No agreement on exactly what the system must do  No comprehensive high-level design  Difficult coordination between team members ▪ How do we know what we should be working on ?  What happens if someone leaves?  How do we bring all the pieces together?

 Requirements  Determine exactly what the system must do. Generally, say nothing about how it does it.  A requirements specification document is produced.  System Design  High-level design breaks the system in to pieces (modules) ▪ Describe how each of the pieces work and communicate.  Low-level design ▪ Write pseudo-code for all the modules  Design documents are produced

 Implementation (Coding)  Typically cited as expected to take 10-15% of project time.  Testing  Unit testing  Integration Testing  Deployment  Deliver the system to the customer ▪ Sometimes this is the first time the customer has seen the system work!

 Maintenance  Debug problems  Make Enhancements  This phase is acknowledged to be the most expensive

 Follows other engineering disciplines – “Have a blueprint before you build anything”  The entire system is planned from the beginning, allowing design to be comprehensive.  The customer is told what they will get from the beginning  Good for contracts, at least on the surface  Module breakdown provides parallelism of effort.

 The less sure we are about what we want the more expensive it will be  What happens if the project is cancelled before deployment?  How do we keep all the documents consistent?  How do we know that the system will solve the user’s problem?  How do we know how long things will take?  It is unclear how effective it is.

- Discussion of Chapter 1 in Martin and Martin

 We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan

 That is, while there is value in the items on the right, we value the items on the left more.

 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.  Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.

 Businesspeople and developers must work together daily throughout the project.  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

 Working software is the primary measure of progress.  Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.  Continuous attention to technical excellence and good design enhances agility.  Simplicity – the art of maximizing the amount of work not done – is essential.

 The best architectures, requirements, and designs emerge from self-organizing teams.  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

 Relatively new software development process  Very clearly defined roles for the development team (Development) and the management team (Business)  Extreme Programming Explained – Embrace Change ▪ Kent Beck, 2000, 2005  An incremental software development process  One of a family of “agile” development processes  Less formal specification and design

 In XP, user requirements are expressed as stories  Stories are determined in meetings between customers and developers  Sample Stories:  A user logs into the system  A user makes a deposit to their account  Stories are recorded on index cards  Developers estimate the work required to implement a story

 A release is software that is delivered to the customer  In extreme programming (XP), releases are made frequently. (approximately every 3 months)  Releases consist of working code, but they are usually snapshots of works in progress.  Releases allow the customer to see how the system is developing and react to problems at early stages (provide feedback)  The customer determines which stories are included in the release, constrained by a budget determined by the previous release.

 Releases are implemented through a series of iterations.  Iterations produce working software demonstrated every 1-2 weeks to get user feedback  Iteration Plan  Collection of stories meeting a budget established by developers  Budget is determined by progress made during the previous iteration  Stories are broken up into “tasks”

 Details of user stories specified by the customer  The virtual requirements document  Everyone can read and understand these tests  Once a test passes, it should never be allowed to break for more than a few hours

 Pair Programming  Test-driven Development (TDD)  Refactoring  Open Workspaces  Customers as team members

 Two programmers work together  One types  One watches for errors, makes suggestions, helps  Occasionally switch roles  Benefits  Fewer bugs initially  Two heads are better than one  Information and Ownership Sharing ▪ Both programmers understand this code well  Information Transfer ▪ Learn techniques from each other ▪ Learn about all parts of the system  Isn’t this more expensive?  It doesn’t seem to be

 Change pairs frequently (once per day)  Everyone works on everything

 Improve code without changing its function  Contrary to “if it works don’t fix it” ▪ “If it works, make it better”  Make a series of small transformations to make the code better.  Verify the you have not broken the code  A unified design can emerge.

 All production code is written to make a failing test pass.  Loop ▪ Write a failing test ▪ Make the test pass ▪ Refactor  Result ▪ All production code has unit tests available from the start. ▪ Refactoring can be done with confidence as tests exist to verify correctness.

 The team is not allowed to work overtime, other than during the last week of a release  Overtime is viewed as borrowing time from the future, with the interest being a dramatic reduction in quality

 Programmers do not work in private offices  Everyone works together in one big room  Better communication  Less reliance of formal meetings

 Consider the simplest thing that could possibly work  You aren’t going to need what you think you will need  Reject duplication of code.

 Any pair as the right to check out any module and improve it  Configuration Management supports this.

 Business and Development play the planning game to determine what to do next.

 Each system feature is broken down to 1 or more user "stories.”  e. g., “a student drops a course,” “a user logs in,” “the system is asked to find a specific course that fits in a given schedule.”

 Check in code after one or two hour’s work  Don’t integrate large modules all at once

 Stories are written on index cards ▪ just enough to remember what they are. ▪ We don’t want lots of details.

 name of the story  date  brief description of story  number of "points" the story requires (cost) ▪ estimates are not in hours, they are in points that have a consistent value  Notes  Anything helpful

 rewritten  broken up into smaller stories if they are too large  combined with other stories if they are too small.  discarded

 Phases are cyclical - you will move back and forth between the phases during the course of the game.  Exploration ▪ Determine what new things the system might do.  Commitment ▪ Decide what subset of all possible requirements to purse next  Steering ▪ Update the plan based on what Business and Development learn

Determine what new things the system might do.  Moves ▪ Write a story (Business) ▪ Estimate a story (Development) ▪ Split a story

 Decide what subset of all possible requirements to purse next.  Moves ▪ Business Sorts by Value ▪ Three piles  Essential  Significant business value  Nice to have ▪ Development Sorts by Risk ▪ Three piles  Cost estimates can be precise  Cost estimates can be reasonably precise  Cost estimates cannot be precise

 Set Velocity  Development tells Business how fast the team can work.  Choose Scope  Business chooses the set of cards that will be included in the release

 Update the plan based on what Business and Development learn  Steering Moves: ▪ Iteration ▪ Business picks one iteration worth of the most valuable stories to be implemented. ▪ Recovery ▪ If Development realizes that it has overestimated its velocity, it can ask Business to specify a smaller subset of the current stories.

 New Story  If Business realizes it needs a new story, Business removes stories with equivalent estimates and inserts the new story.  Reestimate  If Development feels that the plan no longer provides an accurate map of development, it can re-estimate all of the remaining stories and set velocity again.

 Velocity  The number of story points we complete each iteration is our "velocity."  Our next iteration will use our current velocity for determining the number of points we can commit to for the next iteration.  Release Planning  Given velocity, Business gets good estimates of the cost of features  Managers use both cost and priority to schedule the development sequence of features.

 Players are just the programmers  No management  Stories are broken in tasks  Tasks are recorded on index cards  Programmers accept responsibility for tasks  Programmers estimate the time required for each task (perfect programming days/hours)  Programmers test and implement tasks using pair programming

 Exploration Phase  Write a task  Split/combine a task

 Commitment Phase  Accept a task ▪ Programmer volunteers to accept responsibility for a task ▪ Estimate a task ▪ The programmer who has accepted responsibility for a task estimates the time required to complete it (usually in perfect days or perfect programming hours) ▪ Set load factors ▪ What percentage of the available time will you work on your tasks? ▪ Balancing ▪ Determine how well the available time matches the estimated task time for each individual – redistribute as necessary

 Steering Phase  Implement a task ▪ Use pair programming ▪ Use test-driven development  Record Progress  Keep track how much time has been spent on each task  Recovery  Reduce task scope of task/story  Remove non-essential tasks  Get more/better help  Ask customer to defer some stories

 Loop ▪ Write a failing test ▪ Make the test pass ▪ Refactor  Most development environments now have direct support for TDD ▪ NUnit is one of the most popular tools for TDD ▪ Microsoft Visual Studio supports a number of TDD tools, as does Eclipse ▪ Both environments support versions of Nunit

 Using Nunit  Create a TestClass with the attribute [TestFixture] [TestFixture] class chessClassTests { }

 Add a reference to NUnit  References | Manage NuGet Packages  Search for NUnit  Install  Add “using NUnit.Framework;” to your test files.  Under Tests | Test Settings  Select “Run Tests After Build”