Jira Is a Microcosm of What’s Broken in Software Development

And this is the twilight-zone reality that software developers are forever stuck in:

Manager: "I need you to integrate the TPS reports with JIRA for a client"

Developer: "Ok, I can look into that"

Manager: "How long is that going to take? Put some story points on the JIRA task."

Developer: "Well, I've never done that before, so I'll have to do some research and I can't really say for sure-"

Manager: "I need you to say for sure. Knock it off with your engineer arrogance and suck it up and help your colleagues. I'm so sorry that I pulled you out of your 'deep flow' state but we're trying to reach our goals here"

Developer: (heavy sigh) "Well, a week maybe? If I can focus on just this and not all the other things I'm currently tasked with-"

Manager: "No, subtask it out to individual tasks of no more than four hours each. And you'll need to spend an hour every day in a status meeting so you can spend five minutes updating the status of your subtasks and listening to everybody else's unrelated statuses".

This gets into the heart of what I consider to be the biggest issue with Jira, especially compared to nearly every other option, and was disappointed this article wasn't about: Jira is almost a poster child for the "inner-platform effect" [1]. Jira isn't so much an "issue tracker" as it is an "issue tracker development environment", with an ugly PM-focused configuration DSL GUI instead of a more useful to developers script language.

Presumably most of Jira's other technical faults derive from there. It's incredibly slow to use, which is about what you would expect of any program suffering from the inner-platform effect. It presumably has to check layers and layers of "configuration data" to do even the simplest tasks. It's easy to assume the databaase backing Jira isn't well normalized or index-optimized, because you can't build "configurable" normalization. (You might get away with profile-based dynamic indexes, but even then that will only get you so far, especially if your tables are key/value soup where traditional relational DBs fall down at indexing.)

Which gets back to the process failures that the article does talk about because it's easy to suffer from something like the inner-platform effect when your target audience (PMs) don't know what they want until they see it (if they ever figure it out), in part because of the impedance mismatch in the decisiondevelopment status flow between PMs and devs. So I would say the "inner-platform effect" is both a symptom, a cause, and an exacerbater of those process issues.

(Though I suppose it would be tough for an article directly pitching a Jira add-on to be too critical of Jira's underlying technical problems.)

[1] https://en.wikipedia.org/wiki/Inner-platform_effect

Engineering really doesn't have to be like that. I've worked for companies where the leaders took care to push context down, not decisions. When done right, results are very tangible, and (most) of the devs much happier. A few devs struggle and feel lost - probably the ones you want least on your team.