How to write bad software: Standardize nothing
How to write bad software:
Standardize nothing. Let each developer pick their own conventions, patterns, languages, and libraries.
Ignore quality. Optimize solely for velocity. Skip reviews, conversations, meetings, pairing, user acceptance testing, and manual or automated tests.
Ignore security. Skip validation, authorization, and authentication. Blindly trust all inputs.
Repeat yourself. Abstract nothing. Always copy/paste.
Ignore performance. Don’t bother caching, optimizing, bundle splitting, adding DB indexes, or performance testing.
Ignore accessibility. Don’t test different browsers, operating systems, configurations, or screen readers. Assume it’s fine.
Measure success by focusing on gameable metrics like story points, lines of code, number of commits, or tickets closed per developer. Make everyone so focused on optimizing these stats that they’re scared to innovate or improve quality.
Build in a vacuum. Don’t ask for feedback. Code for months without any demos.
Create many long-lived non-prod environments like Staging, QA, UAT, pre-prod, and various oddly named environments like dev1, pre-stage for different stakeholders too. Assume adding yet another environment will fix our problems.
Manually move changes between environments. Create separate committees and approval boards for moving code between them, and only allow rare changes.
Manually deploy a huge amount of code extremely rarely. Since this is hard and risky, create a separate “Release advisory board” that must approve each release.
Require all hands on deck for these giant releases since they are risky and often go poorly. Deploy “off hours” so you can take the whole system down for many hours.
Monitor nothing. Wait for customers to call and complain. Ask them what they did and what error was on their screen to figure out what happened.