The problem is that I've seen far too many examples of people fixing a "clearly a bug" that either turns out to be entirely correct for a reason the developer w

The problem is that I've seen far too many examples of people fixing a "clearly a bug" that either turns out to be entirely correct for a reason the developer wasn't aware of, or even when it is a bug it breaks something down the line that depended on the bug being there (e.g. for a spelling mistake, it turns out some other application was screen-scraping it and depended on that spelling mistake to identify a given page). > In larger teams you probably want to indicate that you fixed something so that the testing team can have something to verify against. In a small team you just fix it and go on without the overhead of making a ticket for every one of those you discover. I think you may have hit the nail on the head there. "to start writing code, you need a Jira ticket" isn't a bad process per se. It's a bad process if you're working on certain types of project e..g. in a small team where everyone intimately knows the codebase and all of its uses. And I think that's what the article was about - blindly applying a process designed for one type of development to an entirely different type.