How to create a perfect software development process that does not work

The best process is the next process

Ultimately, the goal of an engineering manager is to figure out a process that properly treats humans as components of a software system. The Software Process That Always Works seems doable. It is just a business process. If you can just figure out all the branching conditions, a clean, happy path seems clear:

• A customer, who is not an idiot, makes a request, which is a good idea for the customer and for the business.

• A business analyst (who understands the domain) figures out all the details correctly the first time and writes it all out (with drawings) that achieve absolute clarity, and all audiences reads it, all interpretations agree, and nobody falls asleep.

• A product manager prioritizes it versus other work at exactly the right time, making exactly the right decision - not spending their day playing politics.

• A test plan is written by someone that is bulletproof (the test plan not the person), done on time, and everyone reads it.

• A software engineer reads over the requirements and test plan, is not overwhelmed or confused, and types the code into her computer using a Bluetooth keyboard that does not need to be charged. The developer has no further input or questions.

• A second software engineer performs a code review, does not get into an argument about indention, and all checks pass. The second developer has no further input or questions.

• A quality assurance engineer sees this software in the test environment, which is pretty much like production, tests it without having any questions, and passes all the checks. If applicable, the software is shipped to a User Acceptance Test environment, and the customer, who has not changed their mind, is not busy, is not distracted, is not drunk, and is in general emotionally stable, looks over the software and their opinion is that Wow This is Great.

• The software is shipped to production, causes no issues, is a Huge Hit, and Makes Money. The original customer who requested the change (who is still employed and not dead or in jail) is Pleased With the Results and Writes a Big Check.

• Everyone gets paid, is happy with their pay, gets along with their coworkers, and easily communicates along well-defined interfaces throughout this process.

It is just a business workflow, after all - this seems like it would work, right? If you sit down and think of some trivial examples, it seems like it can work out just fine. All of your experience as a software developer indicates that this could work if you just forget about all your experience as a software developer.

If this process fails at any one step, rethink the entire thing to keep trying to achieve The Software Process that Always Works. Rewriting a process is easier than rewriting software, and changing your process just means you are learning.

Obvious changes you can make:

• Migrate to a new tool: move to Jira or away from Jira. Change your source control and branching strategy for security reasons that are not explained.

• Implement scrum, lean, agile, SAFe, NIMBLE¹, Carousel², or asshole-driven-development³.

• Tweak the process by adding more processes; every time you fail, add a double-check for each past failure, like adding unit tests for bugs.

• Change the people involved: make someone you don’t like in charge of the double-checks or the process overall. Give the process to a team of people who hate each other, and give them a name like Guiding Committee, Governance Board, or United Nation of Assholes.

• Change the North Star - how things are measured and viewed as successful or not - from velocity to bug count, average card age, QA-go-backs, or developer-resignations-per-sprint.

Keep making changes without learning until you find The Software Process that Always Works. Just like you finished that final version of every piece of software you ever worked on.

1. This is not a real thing.

2. Not a thing. You could make it one.

3. Very much a thing.