Software Development Lifecycles

1) 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
- 12x12: 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

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

3) Sturdy vs. Agile

Two camps currently dominate the debate about software development
Sturdy: measure twice, cut once
- Think through users' needs, design, and possible problems before starting to code
- Inspired by traditional engineering (in which late changes are very expensive)
Agile: lots of small steps, with continuous testing and refactoring
- "No battle plan ever survives contact with the enemy." (Helmuth von Moltke)
- They refer to the sturdy camp (disparagingly) as Big Design Up Front (BDUF)
- Inspired by open source and 1990s web development
Differences in practice are much less than the differences in rhetoric

4) Boehm's Curve

Both methodologies are responses to Boehm's Curve

Figure 26.1: Boehm's Curve

Sturdy: aim carefully so that problems don't arise
- The cheapest bug to fix is one that doesn't exist
Agile: continuously correct course
- No point trying to aim at a moving target, and real-world targets always move

5) Which One Is Better for Scientists?

Customers and funding agencies are (understandably) reluctant to fund "we'll make it up as we go along"
- But on the other hand, this is a good description of research
Factors affecting choice:
- How well the team understands the problem domain, tools, etc.
- How stable the goals are
- How many people are involved
If you don't know enough to make long-term predictions with confidence, use agile
- This means every genuinely new project ought to start agile
If hundreds of people are involved, frequent course corrections will be painful
- Though many agile advocates disagree

6) Vision

First step in any project is answering "what?" and "why?"
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

7) Making Up an Elevator Pitch

Exercise: have everyone on the team replace the bits in italics with words of their own
- Do this independently, then compare answers
Just as important for solo projects!

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

8) Agile Development

Start with agile because it's a closer fit to conventional research practices
Arose in the 1990s to cope with:
- Ever-changing requirements
  - Six-month iterations were longer than the lifespan of the average dot-com
- Internet time
  - Web-based delivery makes it possible to "ship" a new version whenever you want
Based on very short development cycles (a minutes to a month, but no longer)
- Because that's as far out as most people can reliably predict effort or needs

9) Extreme Programming

Best known form of agile in the early days was Extreme Programming (XP)
Took all the key ideas of agile to the limit:
- Stand-up meeting at the start of every day
- Customer always available for consultation
- Test-driven development
- Pair programming
  - Two people at each workstation
  - One typing, the other reviewing (and learning) in real time
- Constant refactoring
- No functionality is added until it's needed
  - You Ain't Gonna Need It (YAGNI)
Development cycle:
- Choose the next small feature to add
  - More properly "micro-feature"
- Write some tests to make sure it's working
  - Yes, these are supposed to fail
- Write enough code to make all tests pass
  - Not just the newly-created tests
- Refactor
- Check in to version control
Pitfalls:
- Customer often isn't always available
- Many people prefer not to pair program
  - Except when faced with a hard bug, or when bringing a new team member up to speed
- "A week of refactoring can sometimes save you an hour of thought"

10) Scrum

Less extreme, but more workable (and now more popular)
Doesn't specify detailed working practices
- Though some are found in almost all teams

Figure 26.2: Scrum Lifecycle

11) Scrum Roles

Product owner
- Defines and prioritizes features
- Sets release dates
- Accepts or rejects work
Scrum master
- Shield the team from external interruptions
- Makes sure development practices are being followed
- Makes sure individual team members are being productive
Team member
- Half a dozen developers (plus or minus half a dozen)
- Cross-functional: programmers, testers, UI designers (or all the same people)
- Membership changes only between sprints

12) Scrum Key Practices

Sprint planning meeting held at the beginning of each iteration
- Analyze and prioritize current product backlog
- Select overall goal for sprint
- Decide how to achieve the goal (design)
- Create a sprint backlog from the product backlog (more about this below)
- Estimate backlog in hours
  - Nothing should be longer than a couple of working days
  - Anything that is should be broken into smaller testable/deliverable chunks
Daily scrum meeting
- Every morning, 15 minutes long, standing up (to make sure it stays 15 minutes long)
- Everyone says:
  - What they did yesterday
  - What they are going to do today
  - What stands in their way
- Not a status update, but rather making commitments to colleagues
Sprint review held at the end of the iteration
- Team presents what it accomplished
  - Demo, not slides
  - And yes, everything can be demo'd
Sprint retrospective also held at the end of the iteration
- What do we want to start doing?
- What do we want to stop doing?
- What do we want to keep doing?

13) Scrum Artifacts

Product backlog
- A list of all the things the customer wants the product to be able to do
- Phrased in the user's terms, not the developer's
  - E.g., "visualize the similarity between the specified protein and the best 10 matches in the database"
- Updated and re-prioritized by product owner at the start of each sprint
Sprint goal
- (Very) brief description of what value this sprint is going to deliver
- E.g., "Extend the program's visualization capabilities"
- Every activity is measured against this
Sprint backlog
- The subset of the product backlog to be done in this sprint
- Estimates for work remaining on each task are updated daily
- "What should be in the backlog for the next sprint?" is often an item
Burndown chart
- Shows work remaining per item vs. elapsed time
- Not necessarily monotonically decreasing: sometimes work will uncover more work
- The best predictor of when something will actually be finished

14) A Sturdy Alternative

Longer interactions (typically several months)
A better fit for large teams and well-understood problem domains and tools

Figure 26.3: Sturdy Lifecycle

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

16) 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 large, long-lived, distributed teams

17) 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?

18) Waterfalls...

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.4: The Waterfall Model

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

19) The Spiral Model

The spiral model [Boehm 1988] wraps the waterfall around itself

Figure 26.5: The Spiral Model

Go through the waterfall cycle over and over again, each time on a larger scale
- Royce actually advocated doing this, 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
- If (when) you run out of time, you'll have something ready to deliver

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

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

22) 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
- Write for who you were when you started the project
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?
- 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

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

24) 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 [Orwell XXX]
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

25) Step 4: Prioritization

There's never enough time to build everything
- So which features are most cost-effective to develop?
Decide using a 3x3 grid
- Rank each feature low-medium-high on importance and effort
- More honest than the false accuracy of a 1-10 scale

Figure 26.6: Ranking Features

26) 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
Best to start big ones early, in case they run over
But knocking off a few little ones will teach you useful things about the code
- 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

27) 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 make them any happier
- It's better to live up to small promises than break big ones

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

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

30) 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.7: Burn Rate

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

31) 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 2006]
- Any more than that, and the mistakes they make will actually cost you time overall

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

33) Summary

There is no "best process"
Choose one based on:
- How well you understand the problem and the technology
- How stable the requirements are
- How big (or distributed) the team is
Most important thing is that everyone is playing by the same rules...
...and that you adjust the process to reflect reality, rather than trying to do the opposite