How to deliver software: Difference between revisions
From YM2149.org
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 19: | Line 19: | ||
* eat the frog, within reason | * eat the frog, within reason | ||
** not eating the frog risks development that may need to be partially undone | ** not eating the frog risks development that may need to be partially undone | ||
** another way of looking at this is taking opportunities to get ahead of the curve e.g. not treating deployment as an afterthought | |||
** whereas picking too hard an option is at risk of delaying delivery due to too many surprises | ** whereas picking too hard an option is at risk of delaying delivery due to too many surprises | ||
*** when migrating a dozen services for example, do the easiest one first to find out what the baseline surprises are | |||
** 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 | ** 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 | ||
| Line 28: | Line 30: | ||
** also merging a feature branch into the default branch does not build upon questionable code | ** 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 | * a ticket is done when the changes are in production | ||
* split work feature by feature, not layer by layer | ** 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 | ** descope tasks that can later be fixed forward | ||
* squash merge makes the history less useful for investigations or revert | * squash merge makes the history less useful for investigations or revert | ||
** in particular | ** 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 | * merge your own pull requests, own that responsibility | ||
* keep your own tickets up to date | * 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 | |||
[[Category:Programming]] | [[Category:Programming]] | ||
[[Category:Wisdom]] | [[Category:Wisdom]] | ||
Latest revision as of 08:54, 23 February 2025
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
- another way of looking at this is taking opportunities to get ahead of the curve e.g. not treating deployment as an afterthought
- whereas picking too hard an option is at risk of delaying delivery due to too many surprises
- when migrating a dozen services for example, do the easiest one first to find out what the baseline surprises are
- 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
