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.
My favorite variants of this phenomena are "let's just add a column instead of creating a new table" and "let's add a boolean argument instead of creating a new function."
I usually do the inverse: who knows what additional data we'll want to store for each row, let's put there a jsonb column, store anything not clearly critical there, and add columns or tables as these jsons get populated and used.
Agreed. It should be almost as simple to create a sub-task (of any task) as it's to comment. Also convert a comment to sub-task. Browsing is another problem...
And there a fundamental impedance mismatch between these tools and actual work rears its ugly head. Work is structured as a dependency graph - a DAG. To complete C, you need to do A and B, but a part of B depends on a part of A to be done, etc. Yet these tools insist on a list, or a very flat tree (a task and maybe a subtask, but no sub-subtasks).
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.