Development methodologies: Difference between revisions

From ym2149.org
Jump to navigationJump to search
No edit summary
No edit summary
Line 1: Line 1:
* 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
* 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
* 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, 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
* 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
Line 8: Line 8:
* 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 - FIXME


[[Category:Programming]]
[[Category:Programming]]

Revision as of 12:28, 22 March 2024

  • 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
  • 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 - FIXME