Practices of an agile developer

Blame doesnn’t fix bugs. Be outcome oriented.

Don’t fall for the quick hack (technical debt).

Criticize ideas, not people

Do what’s right (even though it may be difficult to be brutally honest).

Keep up with changing technology.

Raise the bar for you and your team (brown-baf sessions)

Learn the new; unlearn the old.

Keep asking Why.

Tackle tasks before they bunch up.

Let your customers decide. Empower the customer.

A good design is a map; let it evolve.

Choose technology based on need.

Keep project releasable at all times.

Integrate early, integrate often.

Deploy your application automatically from the start.

Develop in plain sight. Actively seek feedback.

Develop in increments.

Estimate based on real work.

Use automated unit tests.

Use it before you build it (TDD)

Different makes a difference (run unit tests on each supported platform and env combination)

Create tests for core business logic. (have the customer verify these test)

Measure how much work is left.

Every complaint holds a truth.

Write code to be clear not clever.

Comment to communicate.

Actively evaluate trade-offs

Write code in short edit/build/test cycles.

Develop the simplest solution that works.

Keep classes focused and components small.

Tell, don’t ask (tell an object what to do)

Extend systems by substituting code (delegation preferable to inheritance)

Maintain a log of problems and their solutions.

Treat warnings as errors.

Attack problems in isolation.

Handle or propagate all exceptions.

Present useful error messages.

Use stand-up meetings.

Good design evolves from active programmers (architects should code)

Emphasize collective ownership of code

Be a mentor

Give others a chance to solve problems.

Share code only when ready.

Review all code.

Keep others informed by publishing your status, ideas and neat things you are looking at.