There is a scene in Malcolm in the Middle where he needs to fix the lightbulb, but then the shelf is broken so he goes to get a screwdriver, but then the drawer is awfully squeaky so then he needs to go to Home Depot but the car is broke down...you get the idea.
Garage Fixing is when you open up your code and realize that you need to fix the way this method is working. But the variable is misspelled, so you need to fix it. But to do that you need to make another package of your Java project and then release it. But you can't do that until you fix the deploy. But the deploys won't work until you pass the tests. you could configure Jenkins to ignore the tests, but then you need to find a way to configure without breaking Jenkins, and you'd first need to upgrade Jenkins to get that ability. On and on and on.
Or it's when you want to install a package, a node package or a new gem, but you need to upgrade bundler. But to upgrade bundler you need to fix your RVM. To fix RVM you need to fix your zsh profile. But that won't work until you fix brew.
I'll give an example from a project I'm working on right now. My goal is to release a React project via AWS Amplify. However when I try to npm install amplify, I get:
npm error Could not resolve dependency:
npm error peerOptional typescript@"^3.2.1 || ^4" from react-scripts@5.0.1
npm error node_modules/react-scripts
npm error react-scripts@"^5.0.1" from the root project
npm error
npm error Conflicting peer dependency: typescript@4.9.5
npm error node_modules/typescript
npm error peerOptional typescript@"^3.2.1 || ^4" from react-scripts@5.0.1
npm error node_modules/react-scripts
npm error react-scripts@"^5.0.1" from the root project
ERESOLVE could not resolve
Now the question is: I am compelled to take a detour. Really all I want to do is publish an app online. Do I need to go down the rabbit hole of understanding how peer dependencies and dependency resolution work in order to proceed? Or is this a distraction? Am I laying the groundwork, or am I getting offtrack? Am I jumping through unavoidable hoops, or am I sidequesting?
Laying the groundwork: I MUST do this before I get to the main task, "fun" thing, and I understand that this is necessary.
Jumping through hoops: I MUST do this before I get to the main thing, and I may not entirely understand the exact relevance but here we are.
Sidequesting: I have convinced myself I must do this in order to get to the main thing but really I have distracted myself from finding a simpler, straightforward alternative solution.
Garage fixing: An ambiguous state; I find myself doing a bunch of work that doesn't seem directly related to the main priority, and I don't know if it's necessary or sidequesting.
In this example, spending the next several hours researching peer dependencies might be sidequesting if there's a quick alternative just to get to the finish line. in this case, I could run npm config set legacy-peer-deps true and temporarily see if I can still deploy. This tells me this is the only bottleneck and at least I have the option to do this for showcasing an app. Would I do this in production? Likely no, but at least you can explain to your team that you are able to get it working, and the ONLY thing keeping you from having a viable product to ship is this one flag. Then you can dedicate a sprint to figuring out that last bottleneck.
When you find yourself "fixing the garage", ask yourself: Is this necessary to fix the lightbulb? Or am I sidequesting?
Top comments (0)