Development methodologies: Difference between revisions
From YM2149.org
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| (16 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
* Fear-driven development - tests would expose bugs so don't write any, a cool new lib would break things as we don't have enough tests so ban that, a cool new lib would confuse our developers because we treat them as a liability instead of investing in people, deployment to prod would expose bugs so let's not do that, and so on | * Fear-driven development - tests would expose bugs so don't write any, a cool new lib would break things as we don't have enough tests so ban that, a cool new lib would confuse our developers because we treat them as a liability instead of investing in people, deployment to prod would expose bugs so let's not do that, and so on | ||
* Pearl clutching-driven development - any hint of creativity must be extinguished | * Pearl clutching-driven development - any hint of creativity must be extinguished | ||
** Umm-ahh driven development - reward innovation done openly and candidly with a pile-on | |||
** also see https://en.wikipedia.org/wiki/Wikipedia:Pearl-clutching | |||
* Gotcha-driven development - instead of publishing guidance to empower teams to avoid problems, send the results of scans straight to the top of their backlog without context | * Gotcha-driven development - instead of publishing guidance to empower teams to avoid problems, send the results of scans straight to the top of their backlog without context | ||
* Emoji-driven development - replace logging critical to investigating incidents with pretty logging, or no logging at all | * Emoji-driven development - replace logging critical to investigating incidents with pretty logging, or no logging at all | ||
* kim jong un-driven development - so much critical info only exists in the engineering manager’s head you have to frantically jot it down when they’re speaking, and don't dare log off until they've stopped | * kim jong un-driven development - so much critical info only exists in the engineering manager’s head you have to frantically jot it down when they’re speaking, and don't dare log off until they've stopped | ||
* Playing the security card - get a team to drop everything to fix a nebulous security issue, never explain the impact of leaving things as they are | * Playing the [[security card]] - get a team to drop everything to fix a nebulous security issue, never explain the impact of leaving things as they are | ||
* Aspect-oriented programming - an admission that the code is unmaintainable, and commitment to keeping it that way | * Aspect-oriented programming - an admission that the code is unmaintainable, and commitment to keeping it that way | ||
* Reddit-driven development - how dare you question the hive mind's golden opinion | * Reddit-driven development - how dare you question the hive mind's golden opinion | ||
** must not show weakness by being wrong in public | ** must not show weakness by being wrong in public | ||
** actually perfect is not the enemy of good | ** actually perfect is not the enemy of good | ||
** ignore concerns due to them not being raised in an obsequious enough way | |||
** can't/won't see past own universally applicable experience | |||
* Wishful thinking-driven development - this code i've thrown at the screen will stick, or too bad if it doesn't | |||
* Maturity model-driven development - forget progress, rules are now the deliverable | |||
* Self-fulfilling prophecy-driven development - apply agile in the most cursory box-ticking way so it's only ever seen as a pain point | |||
** advanced piss-takers will run retro like church | |||
* Milkshake duck-driven development - bad developers exist and supporting them would harm my fragile image, so treat all developers as a liability | |||
* Flat earth-driven development - ignore all evidence that the code works as it should, insist on reading it for yourself | |||
== Tech guardrails == | |||
* normalise treating developers as a liability | |||
[[Category:Programming]] | [[Category:Programming]] | ||
Latest revision as of 22:48, 22 February 2025
- Sweep it under the carpet-driven development - never investigate any root cause, just throw code at the screen until the problem appears to go away
- Plate spinning-driven development - we don’t have time to write automated tests, instead n developers must perform an increasing amount of incomplete manual testing forever
- Fear-driven development - tests would expose bugs so don't write any, a cool new lib would break things as we don't have enough tests so ban that, a cool new lib would confuse our developers because we treat them as a liability instead of investing in people, deployment to prod would expose bugs so let's not do that, and so on
- Pearl clutching-driven development - any hint of creativity must be extinguished
- Umm-ahh driven development - reward innovation done openly and candidly with a pile-on
- also see https://en.wikipedia.org/wiki/Wikipedia:Pearl-clutching
- Gotcha-driven development - instead of publishing guidance to empower teams to avoid problems, send the results of scans straight to the top of their backlog without context
- Emoji-driven development - replace logging critical to investigating incidents with pretty logging, or no logging at all
- kim jong un-driven development - so much critical info only exists in the engineering manager’s head you have to frantically jot it down when they’re speaking, and don't dare log off until they've stopped
- Playing the security card - get a team to drop everything to fix a nebulous security issue, never explain the impact of leaving things as they are
- Aspect-oriented programming - an admission that the code is unmaintainable, and commitment to keeping it that way
- Reddit-driven development - how dare you question the hive mind's golden opinion
- must not show weakness by being wrong in public
- actually perfect is not the enemy of good
- ignore concerns due to them not being raised in an obsequious enough way
- can't/won't see past own universally applicable experience
- Wishful thinking-driven development - this code i've thrown at the screen will stick, or too bad if it doesn't
- Maturity model-driven development - forget progress, rules are now the deliverable
- Self-fulfilling prophecy-driven development - apply agile in the most cursory box-ticking way so it's only ever seen as a pain point
- advanced piss-takers will run retro like church
- Milkshake duck-driven development - bad developers exist and supporting them would harm my fragile image, so treat all developers as a liability
- Flat earth-driven development - ignore all evidence that the code works as it should, insist on reading it for yourself
Tech guardrails
- normalise treating developers as a liability
