Whack-a-bug or Treasure Hunting
Mrs. Harris in ten years: My husband coined the phrase 'whack-a-bug'
It depends on the craftsmanship of the code
“How long will this take to fix?”
“I don't know.”
Fixing a bug is like hunting for treasure. Without good craftsmanship:
- You can't estimate time to fix until you find the bug
- Once you find it, it's practically fixed
The first things I ask on new projects:
- Do you have automated tests?
- Do you have logging?
- Do you have automated build & deployment pipelines?
“Why do these matter? I want NEW features!”
I'm with you. But you have OLD software. And when it breaks, it takes a long time to FIND the bugs, let alone fix them.
Logging helps us find bugs.
Logging is the treasure map
If we want to hunt treasure, we need a map. Logging is the map.
“Arrr, yer program be crashin' right here, on this very line o' code, with this nigh-on precise reasonin'... I wager there's buried treasure in these waters!”
“My vessel hath returned bereft of gold, which circumstance doth constitute a grievous flaw in the design. I am persuaded that treasure of auric splendour doth await discovery yonder. Pray, how long shall it require for you to unearth it? ...”
(I love AI)
Whack-a-bug
“Whenever we push changes in one area, we break something else!”
This is what I coined whack-a-bug.
“My husband coined the phrase 'whack-a-bug'”
Some purists say “code that isn't tested doesn't work”.
Tests assert our code works as intended. Over time, we collect hundreds, thousands, or more of these little automated functionality verifications. They run automatically anytime we want to run them, typically within just a couple minutes. Now, instead of hoping our changes don't cause other bugs to pop up after deployment, we can know before deployment.
“But won't this slow down each new feature?”
Yes, and you can work all night with enough coffee.
You get early immediate gratification without tests, but you'll quickly reach a wall of complexity (I think I coined this, too). Then everything falls apart and you need to rehab (your code).
Automated deployments are software conveyor belts
Deployment pipelines ensure we deploy the same thing, the same way, every time.
Also, we hook our tests into the pipeline so we never deploy code with failing tests. If the tests fail, the pipeline fails.
Crafting software has a lot of iterations. Reducing the time of those iterations and guaranteeing consistency is critical for optimizing efficiency of delivering software.
Spending manual time deploying software makes things slow. Pipelines are really easy to automate these days, too, no matter what platform you're using (GitHub, GitLab, Azure DevOps, etc).
Maybe best of all, it dramatically improves the morale of your dev team, and that's worth a lot.