Development Process

Conrad Huang

March 31, 2014

Portions Copyright © 2005-06 Python Software Foundation.

[How To Write Good Code]

Introduction

  • There's more to building a house than nailing boards together
    • Have to make sure the pipes are put in before the drywall goes up
    • Satisfy building code regulations
    • Make sure everyone on the team is productive (not just busy)
  • This lecture covers the equivalent topics for small-team software development
    • 12×12: up to a dozen people, working for up to a year
    • All of these ideas apply to people working on their own for two weeks or more

Design vs. Agility

  • Two camps currently dominate the debate about software development
  • Big Design Up Front (BDUF): measure twice, cut once
    • Think through users' needs, design, and possible problems before starting to code
  • Agile: lots of small steps, with continuous testing and refactoring
    • “No battle plan ever survives contact with the enemy.” (Helmuth von Moltke)
  • Both are responses to Boehm's Curve
      [Boehm's Curve]

      Figure 26.1: Boehm's Curve

    • BDUF: prevent problems from happening at all
      • The cheapest bug to fix is one that doesn't exist
    • Agile: catch problems while you're still at the low-cost end of the curve
  • Differences in practice are much less than the differences in rhetoric

Project Lifecycle

  • Very few individuals or teams stick to textbook rules
    • Teams always adapt processes to local needs and personalities
    • Remember: reality matters more than rulebooks
  • No matter what the official process is, most well-run medium-sized projects follow a similar path

[Project Lifecycle]

Figure 26.2: Project Lifecycle

Step 0: Vision

  • A vision statement is a one- or two-sentence summary of the project
    • Also called an elevator pitch
    • Helps keep everyone pointed in the same direction
    • A good way for project members to introduce themselves at conferences and trade shows
  • Exercise: have everyone on the team replace the bits in italics with words of their own
    • Do this independently, then compare answers
  • Part Boilerplate Example
    Problem statement The problem of only being able to simulate invasion percolation on regular 2D grids
    Target market affects scientists who work with composite materials,
    Impact who currently have to extrapolate from regular models.
    Solution Our solution, a set of enhancements to InvPerc,
    Key technical feature handles any structure that can be represented as non-overlapping regions.
    Competition Unlike PI2D and other simulators,
    Differentiator it can read standard CAD files as well as IP2-format grid files.
  • Just as important for solo projects!

Step 1: Gathering Requirements

  • Single biggest cause of project failure is failing to get the requirements right
    • Boehm's Curve again: building the wrong thing is the most expensive mistake you can make
  • Start by asking what problem the software is supposed to solve
    • What do you want to be able to do that you can't right now?
    • What does the existing software do that you don't want it to?
    • What does it make you do that you don't want to?
  • Organize requirements as point-form list
    • Give each one a unique name
    • And keep the list under version control

What Requirements Are and Aren't

  • Good requirements are complete and unambiguous
    • “The system will reformat data files as they are submitted“ is neither
  • Instead:
    • Only users who have logged in by providing a valid user name and password can upload files
    • The system must allow users to upload files via a secure web form
    • The system must accept files up to 16MB in size
    • The system must accept files in PDB and RJCS-1 format
    • The system must convert files to RJCS-2 format before storing them
    • The system must present users with an error message page if an uploaded file cannot be parsed
    • etc.

Requirements

  • A contract amongst the various stakeholders
    • Overly formal for two-person research prototypes
    • But essential for distributed teams

Step 2: From Requirements to Features

  • Figure out what features you need
    • What do you have to build in order to accomplish XYZ?
    • How will you tell that it's working?
    • Yet another point-form list…
  • Relationship between requirements and features can be very complex
    • One feature can (help) satisfy many requirements
    • One requirement may require many features
  • Traceability once again:
    • Why does each feature exist?
    • How is each requirement being satisfied?
    • Who said so? When?

Waterfalls And Why Not

[The Waterfall Model]

Figure 26.3: The Waterfall Model

  • This looks like the start of the waterfall model [Royce 1970]
    • Describes development as flowing through several distinct phases
    • Requirements analysis to design to implementation to testing to maintenance
  • But...
  • But:
    • If different people are responsible for different phases, then no one has to deal with the consequences of their mistakes
    • Whoever is responsible for testing has to make up all the lost time from the previous phases
    • Time lag: it can take a long time for changes in requirements to filter through to the finished product
    • No one actually ever works this way in real life anyway

The Spiral Model

> [The Spiral Model]

Figure 26.4: The Spiral Model

  • The spiral model [Boehm 1988] wraps this around itself
    • Go through the waterfall cycle over and over again, each time on a larger scale
    • Royce actually advocated doing this too, but most people have forgotten that
  • Key ideas:
    • The code teaches you about the problem
    • Customers can only find out what they actually want by playing with a working system
  • But Boehm still envisaged:
    • Cycles lasting from six months to two years
    • And division of labor

Enter the Extremists

  • Extreme Programming (XP) arose in the 1990s to cope with:
    • Ever-changing requirements
    • Internet time
      • Six-month iterations were longer than the lifespan of the average dot-com
    • Web-based delivery: it's possible to “ship” a new version whenever you want
  • Basic ideas:

Pitfalls

  • Requires a lot of self-discipline to stop it degenerating into pure hackery
  • Funding agencies are understandably reluctant to fund a project whose deliverables will be made up along the way
    • On the other hand, this is a good description of research…
  • Not as well suited to large projects or teams
    • But this is changing as web-based collaboration tools improve

Step 3: Analysis & Estimation

  • Next step is analysis & estimation (A&E)
    • How can each feature be implemented?
    • And how long will it take?
  • Where possible, investigate two or more options
    • Plan A: only solve three quarters of the problem, but can be implemented in a week
    • Plan B: does everything and more, but will take three months
  • Write throw-away code to become familiar with new libraries and tools
    • Keep it under version control
    • But do not let it find its way into the application

Step 4: Prioritization

[Ranking Features]
  • Now it's time to prioritize
    • Which features are most cost-effective to develop?
    • There's never time to do them all
  • Usual way to do this is to build a 3×3 grid
    • Rank each feature low-medium-high on importance and effort
    • More honest than the false accuracy of a 1-10 scale

Step 5: Scheduling

  • Can now draw up a schedule
    • Throw out everything below the diagonal of the priority matrix
  • Only big choice remaining is whether to do big items first, or little ones
    • Remember to take dependencies into account
  • End result is a list of who's doing what, when
    • Schedule people at 80% of capacity to allow for sick time, interruptions, etc.
  • Yes, it contains a lot of guesswork…
    • …but it's better than nothing…
    • …and estimates improve with practice

Step 6: Development

  • Now it's time to test and code
    • Remember to do them in this order
  • Expect to refine design during early stages of construction
    • If you're still refining the design a week before you're due to ship, something has gone wrong
  • Take time to refactor old code while adding new stuff
    • Your skills (and coding style) improve over time
      • Or the person working on the feature in Version 3.2 knows something the Version 3.1 author didn't
    • The problem changes over time
      • A good solution to last year's requirements may not be a good solution to this year's
  • Describe day-to-day activities in teamware

Tracking Progress

  • Make sure the schedule is always up to date
    • Every developer writes a few bullet points every week
    • Doing this at 9:00 a.m. Monday works better than asking for it at 4:45 on Friday
  • Describe tasks in terms of verifiable deliverables
    • Things that other people can inspect or test
  • Always mark tasks as “done” or “not done”, rather than “X% complete“
    • If you allow percentages, then many tasks will be 90% done for 90% of the lifetime of the project
    • Instead, break tasks down into subtasks that are at most a few days long, and either are or are not completed

Step 7: Finishing

  • Stop adding new features three-quarters of the way through the project
    • No matter how much testing you do as you go along, you'll need time to fix things at the end
  • Shift resources into integration testing and documentation
  • If you're only starting to build the installer now, you've left it too late
    • Installation and upgrade code can be as complex as the application itself
    • Do design, and budget time, when writing A&E
  • Do not ask for a “big push”
    • People can only be productive for 40 hours a week [Robinson 2005]
    • Any more than that, and the mistakes they make will actually cost you time overall

After the Party's Over

  • Always do a post mortem after the project finishes
    • What went right (that you want to do again)?
    • What went wrong (that you want to avoid next time)?
    • Often helps to bring in an outsider to facilitate
      • Feedback is only as useful as it is honest
  • Update the A&Es to reflect what was actually built
    • Forces team members to examine what they got wrong (so that they can improve)
    • Provides a starting point for the next round of development

Development Summary

  • BDUF and XP are diametrically opposed, but both improve productivity
  • So either the way most people develop software is the worst possible…
  • …or what really matters is having a process—any process—so that you have some rules to play by…
  • …and something to improve