This is a collection of thoughts, theories, and takeaways to remind myself of how I want to think about software development. Your mileage may vary.

Agile Planning

  • A release should generally not be larger than 6 months.
  • All stories in a release must be written in order for the release to be estimated.

Documentation

  • The minimum necessary amount of development documentation for a project should never be a separate planned story or task. It is a part of every story or task.
  • Skipping development documentation will ALWAYS cost more than habitually creating it (unless the project is abandoned).

Estimates & Time Management

  • There is no such thing as a fraction of a person.
  • Any development split over multiple working periods will overall take longer than if it were uninterrupted.
  • It is not practical to estimate work to account for interruptions because the quantity, frequency, and impact of interruptions varies.

Meetings

  • All meetings should be scheduled in advance and have a published agenda.

Professionalism

  • When a professional makes a mistake they clean up the mess.
  • Professionals speak truth to power (firmly but respectfully).
  • Hard decisions are best made through the confrontation of adversarial roles.

SOLID

  • Single Responsibility Principle - a software module should have only one reason to change (should be driven by a single owner with a single purpose)
  • Open-Closed Principle - Open to extension, closed to modification; change by adding code rather than changing code
  • Liskov Substitution Principle
  • Interface Segregation Principle - avoid direct dependencies
  • Dependency Inversion Principle - avoid dependencies on volatile concrete elements of a system, prefer stable abstractions

Teamwork

  • Teams take time to form, storm, norm, perform; therefore it makes sense to avoid unnecessarily repeating the form/storm/norm process;
  • There is no such thing as half a person on a team

Testing

  • I will not say something works unless it has been thoroughly tested.
  • Skipping tests is the same as stealing from a future developer. When we skip writing tests we steal their ability to be productive and make cost effective changes to a system.

Other Resources