The Development Process

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
• Send comments

You Can Skip This Lecture If...

• You don't care if anyone else can ever use your software
• You enjoy being frustrated and unproductive
• You're sure that people you've never met will be able to use and modify your software two years from now
• Send comments

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
  • 

    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
• Send comments

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
  • 

    Figure 26.2: Project Lifecycle

• Send comments

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.
Table 26.1: Vision Statement Template

• Just as important for solo projects!
• Send comments

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
• Send comments

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.
• A contract amongst the various stakeholders
  • Overly formal for two-person research prototypes
  • But essential for distributed teams
• Send comments

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?
• Send comments

Waterfalls And Why Not

• Pause for a moment…
• 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
  • 

    Figure 26.3: The Waterfall Model

• 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
• Send comments

The Spiral Model

• The spiral model [Boehm 1988] wraps this around itself
  • 

    Figure 26.4: The Spiral Model

  • 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
• Send comments

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:
  • Each spiral lasts only one to four weeks
  • So requirements gathering can be reduced to collecting a few stories from users, then implementing them
  • Rely on test-driven development, pair programming, and constant refactoring to ensure code quality
• Send comments

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
• Send comments

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
• Send comments

Where Estimates Come From

• Time estimates come from experience
  • You should be able to guess how much code you'll have to write to implement something
  • If you can't, you should think it through in more detail, or write some more throwaway code
• Keep track of how long it takes your team to build things
  • Just as athletes track their times for the 1000 meters, or how much they can bench press
  • The most extreme version of this is Humphrey's Personal Software Process (PSP) [Humphrey 1996]
• Remember to include time for testing, debugging, and documenting
  • Based on average developers and average days, not the best and their best
• Your first estimates will be far too optimistic
  • But the more you estimate, the better your estimates will become
• Send comments

What Goes Into An A&E

• Title page, with feature name and document revision history
• Abstract: two or three sentences that will tell someone browsing dozens of A&Es whether this is one they should read
• Background: summarize the problem for a reasonably knowledgeable developer
  • Imagine writing for who you were when you started the project
  • Don't bother explaining what the Internet is…
• For each alternative:
  • What is it, and how will it work?
  • How long will it take to create? To test? To document? To add to the build and installer?
  • What impact will it have on other features?
  • How certain are you of your estimates?
• References to other A&Es, URLs, pointers to prototypes in the repository, etc.
• In practice, every A&E is different, because every problem is different
  • Requiring team members to express their ideas in a fixed way just leads to fewer ideas
• Send comments

Reviews

• The whole point of writing the A&E is so that other team members can look for holes in your ideas
  • Just like reviewing scientific papers
• Most important thing to look for is people glossing over hard bits
  • “We parse the XML configuration file, and then a miracle happens” is not a good A&E
• Assign specific A&Es to specific people for review
  • Ensures that reviews actually get done…
  • …and that knowledge and decisions are communicated
• It's not just for coders
  • Make sure the people who have to test, document, deploy, maintain, and support all get their say
• Expect to revise the A&E two or three times
  • Stop when everyone is confident the feature can be built in the time estimated
• End result is “just enough” design
• Send comments

What Can Go Wrong with A&Es

• Too much formality
  • Make the format fit the particular design problem, instead of trying to squeeze everything into a standard template
  • You are (probably) not a lawyer: don't try to write like one
    • Read George Orwell's essay Politics and the English Language
  • Don't bother to include detailed change history in the document
    • That's what version control is for
• Not enough formality
  • Everything you leave out because “everyone knows it” is something you might trip over later
• Analysis paralysis
  • You can second-guess yourself forever
  • Once you believe you know how to implement everything, stop writing and start coding
• Send comments

Step 4: Prioritization

• 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
  • 

    Figure 26.5: Ranking Features

• Send comments

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
• Send comments

Science Fiction Scheduling

• Do not shave time estimates to make them fit
  • If you do this, developers will start padding their estimates…
  • …or supplying random numbers, secure in the knowledge that they won't be able make the deadline anyway
• Making up “science fiction schedules” is a very common mistake
  • Yes, people will complain if their feature doesn't make it onto the schedule
  • But putting it in the schedule when you know that schedule is fiction won't actually make them any happier
  • It's better to live up to small promises than break big ones
• Send comments

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 the next lecture
• Send comments

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
• Send comments

Burn Rate

• The real purpose of a schedule is to tell you when to start cutting corners
• Keep track of how quickly items are actually being finished
  • The project's burn rate
  • 

    Figure 26.6: Burn Rate

• If it is 75% of what you predicted, you can:
  • Move the completion date back
  • Replace some tasks with smaller, lower-priority ones
  • Hope that you will miraculously become more productive
• The sooner you do this, the happier you (and your intended users) will be
• Send comments

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
• Send comments

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
• Send comments

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
• Send comments

Exercises

Send comments