How to deliver software

Guidance

• https://wiki.c2.com/?PrincipleOfLeastAstonishment
• https://wiki.c2.com/?KeepItSimpleStupid
• https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
• https://github.com/romenrg/evergreen-skills-developers
• https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good or good enough
• https://en.wikipedia.org/wiki/Worse_is_better e.g. simply propagate errors
  • swallowing errors is a major cause of dev tasks taking excessive time
• https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it (YAGNI)
  • trust future developers to build on what you've done (with any necessary refactoring) instead of building a framework that guesses the requirements they'll be given
  • enforce business behaviour with unit tests to support that refactoring
  • yagni also applies to requirements, functionality that isn't really needed is a major source of tech debt, also see playing the security card
    • consider the impact of not doing a ticket
  • see Defect driven development for YAGNI taken to its logical conclusion
• most of the extreme programming rules
• key construction e.g. in Spring causes identifiers to be unsearchable which interferes with refactoring
  • use something fit for purpose like aridity where such hacks aren't needed
• eat the frog, within reason
  • not eating the frog risks development that may need to be partially undone
  • whereas picking too hard an option is at risk of delaying delivery due to too many surprises
  • you are never going to find a roman road between A and B so it's not a big deal, focus on deliverables of value even if they're not the ones originally planned

Process

• default branch should always be releasable
  • any developer starting a feature branch can be confident of a stable base
  • also merging a feature branch into the default branch does not build upon questionable code
• a ticket is done when the changes are in production
  • do not deploy on friday, allow 24 hours for unforeseen errors
• split work feature-by-feature, not layer-by-layer
  • descope tasks that can later be fixed forward
• squash merge makes the history less useful for investigations or revert
  • in particular when a story results in a refactor commit followed by a feature commit, combining those throws away a ton of information and may make refactoring less attractive to developers
  • they should not be in separate pull requests as refactoring needs context or may be negative work, and benefits from a free round of testing
• merge your own pull requests, own that responsibility
• keep your own tickets up to date
  • in particular, only the assignee knows when it can really be moved to done e.g. experimental cloud resources may need to be tidied up