I like to “embrace complexity.” Any line of code, especially one that introduces a new concept, like a class or a method, is in “addition” to the root problem

I like to “embrace complexity.” Any line of code, especially one that introduces a new concept, like a class or a method, is in “addition” to the root problem we’re trying to solve. The closer the code/data/org-processes/whatever matches the fundamental problems we’re trying to solve, the less complexity we introduce. However, you cannot “remove” complexity! A common mistake I see in software companies is using a single Jira ticket for one or more reports, one or more conclusions, and one or more action items. For example, if we get reports A, B and C, they may all go into a single Jira. Oh, but C is a totally different thing! It’s not a “duplicate”! Ok now someone needs to extract the info from a comment into a new Jira (which no one will... and it’d be a mess if they tried). Now a bunch of discussions are happening in the comments of this mega-Jira. 3 conclusions come out of these discussions — perhaps what the cause is and what should be done about it. Then let’s say there’s two action items, one is a temp fix and one is a long term fix. Unfortunately, I usually see people is the same Jira for both tasks (“Assign this back to me when the temp fix is in so I can do the real fix”). But splitting Jiras up is frustrating. The actual splitting is frustrating to set up, and it’s a pain to browse them. So most Jira workflows remove fundamental complexity (reports vs discussions/conclusions vs tasks) and introduce extraneous complexity (tonnes of fields and workflows that don’t necessarily apply). One should “embrace” the fundamental complexity of the problem(s) they’re dealing with.