3 Project Guidelines from The Pragmatic Programmer

The Pragmatic Programmer by Andrew Hunt provides practical suggestions on all aspects of software development.

Guideline 1 – There are No Final Decisions

“It’s easier to ask for forgiveness than it is to get permission” Grace Hopper

There are no final decisions in software construction. Some requirements will turn out to be easy and some impossible. Product managers that ignore this fact will always be shocked when the future arrives and they are left wondering what went wrong.

Teams become less aligned on decisions when there are more people involved in the decision making process. Separating responsibilities between team members helps teams to make decisions faster.

Guideline 2 – Requirements Will Change

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to cut away.” Antoine de Saint-Exupéry

Recognize which requirements are long-lasting and which are short-term. Business policies like shipping freight every two weeks can change, but the fact that the system is about freight shipment will not. Document these changeable business policies away from the more generic requirement and recommend they are implemented as metadata or configuration in the final application.

Try not to be a slave to formal methods like UML because these methods often require additional explanation to both programmers implementing the specification and the end users buying the software. It is far better to iterate on a technical blog post that can be shared with both users and developers.

Guideline 3 – Estimate from Experience

Estimate to avoid surprises. The best estimate comes from someone who has already created a similar project. Take time with estimates instead of producing them off-the-top of your head.

A simple technique to improve your estimates is to:

  1. Break the software application into components
  2. Estimate the duration to create each component
  3. Compare the actual durations to the measured durations
  4. Use this knowledge to iterate your estimations

Anything critical or difficult should be first implemented as as prototype. This helps to reduce the cost for correcting design mistakes by analyzing and exposing risk at the start of a project.

See also