Martin Fowler

RT @matthiasnoback
Hypothesis: the moment a team adds the requirement that each PR/commit should be related to a Jira issue, it will start accumulating even more tech debt than before.

This requirement adds a penalty for making small, unrelated improvements that get the project in a better shape.

Nov 8, 2022 at 2:48pmWeb
Show threadMartin FowlerNov 8, 2022
posted from twitter, short thread at https://twitter.com/matthiasnoback/status/1589664341938253825
Matthias Noback @[email protected] on Twitter

“Hypothesis: the moment a team adds the requirement that each PR/commit should be related to a Jira issue, it will start accumulating even more tech debt than before. This requirement adds a penalty for making small, unrelated improvements that get the project in a better shape.”

Twitter
Show threadDhruva ⚙️Nov 8, 2022

@mfowler

I wonder if folding PR and Jira into one would help?

IIRC, long time back at NetApp, we had a system/tooling called ‘burt’, it captured bug/feature details and links to commits for code review. Almost all code reviews were done by checking out code locally and using local tools for viewing diffs.

I personally like it better than depending on one-size-fits-all web view approach.

The biggest win was not having to deal with 2 different tools (fragmentation) + searchable ‘burt’.

Show threadDizzyNov 8, 2022
@mfowler agree 100%, obsession to link everything often creates micro management chaos
Show threadShmarkusNov 8, 2022

@mfowler 100000% this! I haven't noticed this before my last project where this is becoming more and more evident.

I have to be more vocal against this trend #projectmanagement

Show threadNino van der MarkNov 8, 2022

@mfowler As long as refactors are related to a particular task, that shouldn't be an issue, as they can be tagged with the same ticket.

What it does slow down is refactoring for the sake of refactoring, which I find a great way to pass the day without actually creating value for the project.

Identifying areas for improvement, and creating tickets for specific reworks or refactoring is a great tool in scoping these changes, and allowing the team to prioritize them as needed.

Show threadTerribleAaronNov 8, 2022
@mfowler i believe this 100% but I haven't seen what people do instead when they have regulatory requirements where it is common to require something like a jira issue for every change. Are commit messages enough for auditors?
Show threadRaul PortalesNov 8, 2022
@mfowler not necessarily.
If the change is small, you can put it inside as "clean as you go"
Or you can create a new Jira for the cleanup.
It might not be intuitive at first, but it's worked out fine for me.
Show threadTamsinNov 8, 2022
@mfowler I'm a big fan of linking to Jira issues - really handy when doing detective work - but commits without should also be allowed. We've allowed commits with an agreed hashtag in the past.
Show threadGuido GüntherNov 8, 2022
Linking to issues is problematic on its own (as URLs change, one might use git offline, etc) but I wonder if explanatory commit messages can also be a penalty? I always saw them as added value for later "git blame" etc to figure out the reasoning for a change.
Show threadAngelo Veltens 🏳️‍🌈Nov 8, 2022
@mfowler not necessarily. I usually do those improvements within a user story, tagging makes it clear that it was done in the context of that story, even if not directly related.
Show threadGuus der KinderenNov 8, 2022
@mfowler If you think of documented procedures as the machinery in which things get produced, then the informal path is often the grease to that machinery. Efforts to make 'the informal' strictly impossible often have an adverse effect on the entire system.
Show threadKyle ShevlinNov 8, 2022
@mfowler absolutely agreed. This bureaucratic theater increases the friction of making code changes to a degree that refactoring, chores, and other important but non-ticket worthy work that keeps a codebase healthy never gets done.
Show threadJojoFromPENov 8, 2022

@mfowler it takes 2 minutes to creates jira ticket and I’m usually moving my ticket from in review directly to done if not needed to be tested by qa.

It’s nice when someone has made an improvement you can get the ticket number in the commit and see whats it’s all about.

I wouldn’t require ticket numbers if the team is not finding it useful for this reason.

Show threadsoaprootNov 8, 2022
@mfowler I have worked places where creating a Jira issue, moving it to the in progress column, and attaching code to it is lightweight enough (and can be done by a developer if they think it is a good idea) that this overhead is greatly reduced. Still, you are right to have us watching out for things which have benefits but also introduce friction: these can add up and have subtle consequences like not doing enough refactoring.
Show threadRomain Nov 8, 2022

@mfowler I've been advocating to a team recently that the "must be related to issue" requirement would only be workable if that *worked for them*, meaning developers must feel that they are gaining something from doing it that would be additional work otherwise...

So I guess yeah... totally agree with the hypothesis...

Show threadPhil Pearl Nov 8, 2022
@mfowler not ever using Jira is a hill I'm more than prepared to die on. But that's probably not your point. In any case, if that happened at my company, with any bug tracker, I'd start looking for another job!
Show threadJake Carpenter 🏳️‍🌈🏳️‍⚧️Nov 9, 2022
@mfowler absolutely agree. I love throwing the ticket # in as an aside when it can point to context, but most tech debt cleanup doesn’t have context and adding tickets just creates friction. PR requirements can possibly create the same friction.
Show threadmkroehnertNov 9, 2022
@mfowler in automotive software you are required to have full linkage between requirements, code changes, and testing.
This usually done via linking Tickets in commits an pull-/merge-requests and can lead to big(er) PRs in which cleanups are sometimes included.