Development Process

Conrad Huang

April 3, 2017

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

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

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

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

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

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