Extreme Programming
For Lilax (Linux Users at LAX), 9 Feb 2002
Streaming video avaailable at lpbn.org
Most Software Projects Stumble or Fail
Common reasons for software project failure:
- Project delivered, but customer asked for the wrong thing
- Project delivered, but doesn't do what customer wanted
- Project delivered, but is buggy
- Project delivered, but doesn't work
- Schedule slips so bad the project is cancelled
Writing specifications is hard
Ideally, customers write a specification for what they'd
like, and programmers write a program according to the specification.
Yet customers often have trouble expressing themselves,
and the specification is nearly always missing crucial details.
Programmers Often Go Off Course
Programmers are perfectionists, and often want to get things
just right. This leads to systems that are beautiful, feature-rich,
and which do something really well. Unfortunately, programmers
don't always know what's important to the customer, and end up
making business decisions based on technical considerations.
This wastes effort and disappoints customers.
Writing Software that Works is Hard
Ever make what should have been a simple change, and
end up chasing down problems it caused for weeks?
It happens more often than you'd expect.
Finishing a Project is Hard
The last 10% of the project -- polishing it so it works well --
often takes 50% of the time.
Testing is hard
Actual quote:
"Don't fix that bug; we just spent a month testing the
product, and if you made any change now, we'd have to test
all over again!"
Scheduling is hard
Nobody really knows how to estimate software projects more than
a month or so in advance.
Yet managers write schedules covering the next six months.
Programmers secretly don't believe the schedules, yet are pressured
into agreeing. The project then slips, everyone works overtime,
the project ships full of bugs, and people burn out.
Best Practices
- Keep the Customer Involved
- Staged Development
- Keep it Simple, Stupid
- Frequent Testing
- Code Reviews
- 40-Hour Work Week
- Coding Standards
Most programmers try to do at least some of these some of the time.
What if...
What would happen if you followed all the 'best practices'
all the time, all the way?
- Let the customer make all the business decisions
- Let the programmers make all the technical decisions
- Finish the project every month -- keep the project in shippable state continuously
- Keep designs as simple as possible, solving just today's problem
- Write your tests before writing your code
- Have automated tests for everything, and run them constantly
- Do continuous code review -- make sure two people understand every
line of code
- Don't work overtime -- if a feature won't be ready by the deadline, cut it
That's Extreme Programming,
and strangely enough, it actually works,
and can help make both customers and programmers very happy.
Write unit tests first!
When writing a new module, programmers should write the
interface first, then the unit test, and only then go
on to implement the module.
This has several benefits:
- Writing the test often reveals flaws in the interface,
letting you fix it before you've wasted time implementing it
- Having the test there when you write the module makes
debugging a snap
- The test, as part of your project's regression test suite,
will help you catch bugs later
[Return to kegel.com]