Jira Is a Microcosm of What’s Broken in Software Development | Hacker News Reader

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

linearb.io

133 pointsdavetwichell176 comments

"Though I think of Jira more like a spreadsheet. Very useful once upon a time. Outdated now. Static. Manual."

This statement is so blatantly wrong that it actually put me off even reading the rest. Spreadsheets are stronger than they've ever been and are never going away, let alone being "outdated." Sure there are products that claim to be "the next spreadsheet" but most of those actually serve a different purpose: no-code app dev.

Jira is a hot mess - I'm genuinely offended in behalf of spreadsheets that the OP would make that comparison.

Funny, from non-dev roles I'd probably put spreadsheets as the the platform for "no-code app dev".

Or rather, the platform for "this is the only b*d tool IT have allowed me to run, and no, I don't have a spare year for them to scope out what could be bodged by a couple of VBA scripts, and doing so would very obviously make my job better. So, for good or evil, it's going to be bodged with a couple of VBA scripts."

I feel like there's a lesson there, though I could be wrong. (Also not sure if that counts as "no-code")

Oh, and seconding the general consensus that websites that flash irrelevant notifications at me are pretty much an instant, hard "no".

Never underestimate the art of the bodge, it's quite literally keeping the world ticking over, perfection has a place but it is rare and fleeting.

I saw a good talk on it from Tom Scott some time ago[0] which I think is relevant.

[0]: https://www.youtube.com/watch?v=lIFE7h3m40U

I assumed the author really meant that using a spreadsheet for project tracking is outdated, static, and manual. Which I agree with. But spreadsheets in general of course are tremendously useful!

I've seen spreadsheets used for project tracking and in general I think they're versatile enough that they're useful tools. What's a better alternative? Jira and other proprietary solutions sound good in theory but I feel like in practice they're just expensive and time consuming since developers and managers need to learn a new tool that might not even have the features you're looking for.

I agree. Spreadsheets are an incredible tool that have stood the test of time. Taking that declaration one sentence farther, they are one of the greatest success stories regarding bringing functional programming into the business world in a way that emphasizes simplicity.

Pro-tip for engineers on spreadsheets: Org-mode & emacs is a great tool for the random spreadsheet you might want to scratch out to compare something or get some running totals or do cost-benefit analysis or whatever. Check out https://orgmode.org/worg/org-tutorials/org-spreadsheet-lisp-... and https://www.gnu.org/software/emacs/manual/html_mono/org.html...

I recently used it to find out how much a certain company owes me based on a monthly guarantee obligation they have continuously fallen short of . I've also used it to do comparisons and find out the maximum I can save on a refinance from different lenders etc, whether I should lease or purchase a car etc.. Very useful!

I think he means a spreadsheet for the purposes of tracking software project progress. Although honestly, if you have a spreadsheet that's longer-lived than a few hours, you should probably evaluate whether you're adopting the best approach.

If you are not a developer, spreadsheets are a tool that lets you get similar capability in many cases. It is basically no-code for accountants, portfolio managers, and non software engineers.

Cool. If you have a spreadsheet that's longer-lived than a few hours, you should probably evaluate whether you're adopting the best approach. You can replace a blown fuse with a penny, too, but you should probably call an electrician instead.

Building/buying a new tool for a job that a spreadsheet can do just as easily because of your hard rule on long-lived spreadsheets feels like a huge waste of company resources.

Your penny analogy is contrived because a penny isn't remotely close to working like a fuse and a mistake can be deadly. No one is going to die if you use a spreadsheet instead of Jira for project tracking.

> Cool. If you have a spreadsheet that's longer-lived than a few hours, you should probably evaluate whether you're adopting the best approach. You can replace a blown fuse with a penny, too, but you should probably call an electrician instead.

or just replace the fuse with a fuse? If you have a spreadsheet and it works for you, why spend time getting a programmer to "do it properly"?

one of the largest Finnish waste disposal companies has a no-code product that runs in excel basically and rakes them millions a year.

Excel + VBA is insanely powerful, and except for the IDE a surprisingly good dev experience. I would have never thought if I my client hadn't insisted..

I'm convinced that every single business out there eventually gets run from an Excel spreadsheet. At the end of the day, they're just rolling up rollups all the way to the top, where some guy is looking at Scenario A vs Scenario B in Excel

Yea spreadsheets were useful before and even more useful now. Agreed, they could be misused but what can't be misused ?

Everything can be misused, but abusing spreadsheets is an art form

I read this as talking about a specific spreadsheet, not the general concept of spreadsheets. Like a specific excel file someone made long ago but it hasn't been updated in a long time and it's difficult to figure out if its up to date or not. It could be worded better.

If you’re going to make judgements so easily you’re going to miss out on a lot of good ideas that people put out there.

Such a beginning does set some expectations of competence, unfortunately :(

I would say 90% of tech ideas that area floated out there are awful and I'm being pretty generous with that number.

I also tripped on this sentence. But the article is not bad if you charitably read "spreadsheet" as "spreadsheets for bug/project tracking."

> This blog is not about how Jira is too complex and over-engineered with features I don’t need.

This blogpost is a microcosm of engineer arrogance (it's also an ad for their product, so all of this is basically a strawman to drive sign-ups. Great content marketing, to bash on a tool people love to hate).

The world is not all about engineers. Jira is a tool for whole companies, which have lots of other departments than Engineering, which are also important, also trying to reach their goals.

I'm so sorry that you got pulled out of your "deep flow" state because an executive is trying to figure out if a project is at risk. You know, she might have a really good reason to worry about that, maybe including information you don't have, like a potential customer who is at risk if the feature doesn't ship.

So suck it up and help out your colleagues.

And if you don't want to be interrupted, then maybe keep your tickets up-to-date, or proactively communicate risks, or sign out of Slack for a few hours, or get your manager to do their job better and be a buffer to protect you from interruptions. None of this is Jira's fault.

Can Jira be a PITA to use - sure, but that's probably because of how your company set it up. You can make Jira streamlined if you try, but it takes active administration, and the people who work in Jira need to be empowered to work on Jira. If you can't get your Jira project to work the way you need, then that sucks, but that's probably Jira being a microcosm of your company's org/power structure, which is a different thing.

Or sign-up for their product, that's really the goal of this post.

Edit: I did not intend to claim that all, or even most, engineers are arrogant people. They certainly are not, at least in my experience. If you are an engineer (I am one, too) please don't read this as me attacking you personally! I am aiming at this kind of blog post, which displays a me-first attitude that I think is unhealthy.

> engineer arrogance

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".

I believe that this kind of work environment must exist, because it's such a strong trope, but honestly I've never really worked in a place like this. I'm sorry for people who do, and who feel stuck there. Not all software engineering is like this.

But if I had a work environment like this, I would be blaming management, and not Jira.

And I should have been clear: not many engineers are actually "how dare you interrupt me, I'm an ENGINEER" types, in my experience.

But I guess I've seen enough blog posts that are so precious about being a software engineer, and so (perhaps unintentionally) dismissive of other people in the org who are also trying to do their jobs, that I probably got triggered a little.

I've never seen a manager operate like that and if yours does then you should look into moving.

Maybe I've had a 30-year string of bad luck.

Considering the litte morality play you typed out includes the exact "developer arrogance" and "flow state" quotes from the OP, I'm guessing this is an exaggeration in anger and it's impossible to argue with until you provide a non-exaggerated example of your 30-year work environment.

> and listening to everybody else's unrelated statuses

This so much. Status meetings tend to follow the org's structure, which is not necessarily logical.

Yes, it is occasionally helpful to listen to something completely unrelated if you have a better perspective. But every day? Waste of time.

> And if you don't want to be interrupted, then maybe keep your tickets up-to-date

My tickets are up to date. Doesn't matter, I'll still get asked about them.

> or proactively communicate risks

Then you are not a team player and such negativity is frowned upon.

> or sign out of Slack for a few hours

While working from home? Are you even working if you are offline?

> or get your manager to do their job better and be a buffer to protect you from interruptions.

Oh yeah. Because telling your superior to do a better job is an outstanding thing to do for your long term work prospects.

> telling your superior to do a better job is an outstanding thing to do for your long term work prospects.

I would hope there's a way to approach that conversation which doesn't involve telling your manager to "do a better job", but which still gets the outcome you're looking for :)

> get your manager to do their job better

"This arrogant engineer I manage just told me how to do my job better! I've already assigned them 14 story points in JIRA, what more do they want me to do?"

This is spot on in my experience. My company is 2+ years into JIRA adoption and it's been messy because everyone tried to bend it to be like the best previous tool, interested of starting with, and honestly evaluating, the default configurations. Now, most teams are slowly circling back to defaults. I find the PM stuff, like Plans, to be fairly well implemented, as are the notifications.

If JIRA has any core issues, it's that it may be _too_ flexible; you can definitely overcomplicate things and get yourself into trouble.

Jira as a representative of process is not bad and the visibility it offers, like you said, is valuable to people outside of your teams as well. But Jira as a product itself is horrid. It's janky, slow and overly complex even for simple things. No matter how much money you throw at it, creating a ticket or updating an epic just takes way too much time and mental effort.

There's a ton of better alternatives, Basecamp, Asana and Trello for example. Sure, they can't be configured as deeply as Jira, but they don't make me want to kill myself either.

OP sounds like someone who's unhappy working on big software projects. That's understandable. But once you're on a big project, you can't keep it all in your head. You can't make your own clever adjustments when problems arise without documenting everything and then taking it through channels.

For what it's worth, sales people have the exact same complaint. They can get testy, too, about executives using software-oversight tools to take away the soul of what they really do. Allow me to change 15% of the words in this piece, and it could become a rebuke of Salesforce and its siblings, as applied to large sales organizations. So the brief allusion to sales seemed way off base.

Process can be exasperating, until you've worked in a big place where there's no coherent process.

No jira sucks. Azure DevOps spoiled me. Going back to jira is painful.

Is not the process, it's the broken tool. Broken file uploads, general wonkiness and all the minor irritations that just don't get fixed.

Managers choose jira. Developers will create a process but will choose tools that work.

Having a process is fine. Implementing that process with tools that have horrible usability is... less fine.

I recognize that this is a marketing blog, but it blames Jira for what are really culture problems and/or bad management practices.

This is an emblematic quote:

    Take subtasks, for example. The invention of Jira subtasks is an affront to dev teams. Clearly someone who has never spoken to an engineer on a dev team created it. It’s the least dev-friendly way possible to get insight into what’s happening with a Jira story.

Behind the bombast, the author assumes that the purpose of subtasks is to provide micro-level insight on progress to PMs. I agree that this would be a misuse of subtasks. Speaking as an engineer, I _love_ subtasks because they help me keep track of my various efforts towards whatever feature the ticket is tracking. Also, I'm the one who defines them!

Jira isn't anyone's favorite software, but it is so configurable that it ends up being an embodiment of your dev process. If you hate it, chances are it's because you hate how you're managed.

This.

Jira is a framework for building something which approximates your actual processes.

> Justin said “I wish Atlassian would sit down with real-world developers and design this product the way we need it to work.”

The way 'you' need it to work. The process 'you' use. I suppose it's possible to build a business on creating a completely bespoke ticketing system for each company which uses one. Over time, that business might gravitate towards building a general toolkit which can be configured for each use case...

Oh look! Jira!

I'd bet that everyone's got their own distinct idea of where subtasks, ticket relations, etc actually fit in their workflow.

The article clearly exists to sell LinearB's product, which will of course work great for people who have the specific problems LinearB are solving with their product.

The rest of us will configure Jira within epsilon of 'works', then spend an afternoon reading about APIs and bash out our own automation service to update X different management tools appropriately for our workflows, and then go down the pub to bitch about management.

I'm not sure why nobody provides a task tracking tool that has tasks organized hierarchically (with chord/circular dependency. This is the real world, regardless of the argument about subjective processes. If you can't see where in your workflow, that 1 task (even from another team's workflow) is impacting multiple other workflows at-a-glance, the tool is too primitive. Subtasks don't cut it.

JIRA is the most popular of all tools on the market, which are glorified gantt points across disparate fragmented views. This is an element of modern tech that makes large organizations hilariously inefficient.

Jira has many project types and products, and the one most commonly used is actually called Jira SOFTWARE. It literally has software in the name. If you're building a product for software companies, you can think about how to do it better specifically for engineers

My problem with subtasks in Jira, is that they're a constantly leaky abstraction. While an epic and task are different on multiple levels, but what makes something a subtask vs a task? This seems like a trivial question, and it's frustrating because it should be, but because Jira has encoded subtasks as a very-similar-but-also-very-different object than tasks, and some actions can only be done against tasks and others only subtasks.

I learned the other day that estimates/story points entered into subtasks do not rollup to parents unless specifically configured. Seems like initial thinking from Atlassian was that subtasks don’t affect scope. https://community.atlassian.com/t5/Jira-Core-questions/Subta...

As a PM, I have no interest in sub tasks. I’ve got enough to do to track at an Epic and Feature/story level. If a dev team wants to use sub tasks to track their process, go for it. If not, I don’t care.

Yes.

I've used Jira for years and never understood the hate.

The only times I have had real problems have been with particular idiosyncratic configurations or conventions that someone at my end has put in.

I feel like the classic UI was a massive pain for configuring workflows, fields and other tasks which also fuelled a lot of the hate. But in the new version at least it's much better IMO.

Have you tried the alternatives like YouTrack?

The Jira UX is amongst the worst in the business.

And yet... there it is, on every workplace with an useless operations team.

I'm not saying Jira is great. I'm just surprised that people, particularly ICs, hate it.

Me either, its easy to search through and find 10+ year old tickets with comments and code reviews/TDDs to add context to old code.

Jira subtasks are weird, we stopped using them and started linking issues instead. The main problem: we still don't know what exactly subtasks are. They look like half-baked feature.

P.S. Look at this discussion for example https://jira.atlassian.com/browse/JRASERVER-4446 , subtasks concept is hard.

I have to agree. Sounds like more of a management issue than a Jira problem.

I spend hours per day in Jira. Half as a PM, and the other half as an IC.

I've never used Jira Classic, so can't comment there.

But Jira Next Gen projects have been great to work with. So much functionality and bloat is stripped out of Next Gen, sometimes too much was removed I think.

I hear people hating on Jira very often, but at least the way our company uses it, it's great.

The only thing I'd really want to change is (1) performance, page load times are frustrating, and (2) ability to easily move a ticket from 1 project to another project without clicking through a 6 step process.

Edit: Regarding Jira's slowness, I'd highly recommend trying the Mac app which is dramatically faster than the web ui.

> performance

By Atlassian’s ToS, you are not allowed to « comment on the performance of the products ». I know no-one thinks this would be enforced here, but I just want to highlight that it doesn’t help a company to improve if they know they can just lawyer-up a problem away and avoid benchmarks and being compared on that topic.

This is from Atlassian's ToS

(d) incorporate any Cloud Products into a product or service you provide to a third party;

does this mean that I can't integrate JIRA into a ticket tracking workflow that I build for my product with IFTTT that creates a new ticket when someone sends an email to a support alias?

(e) interfere with or otherwise circumvent mechanisms in the Cloud Products intended to limit your use;

(f) reverse engineer, disassemble, decompile, translate or otherwise seek to obtain or derive the source code, underlying ideas, algorithms, file formats or non-public APIs to any Cloud Products, except to the extent expressly permitted by applicable law (and then only upon advance notice to us);

(g) remove or obscure any proprietary or other notices contained in any Cloud Product;

Fair enough.

(h) use the Cloud Products for competitive analysis or to build competitive products;

Sure, I mean this is hard to enforce but if the team at Trello was using JIRA while making Trello, Atlassian could just say "hey - stop, no like".

(i) publicly disseminate information regarding the performance of the Cloud Products;

Seriously? I really didn't believe when I saw parent say you are not allowed to comment on performance of the product but I stand corrected. I will not comment on performance of any Atlassian product ever, ever ever. You got me Atlassian, this is what I get for not reading ToS before clicking Accept.

(j) encourage or assist any third party to do any of the foregoing.

Ok.

[0] https://www.atlassian.com/legal/cloud-terms-of-service

Wow, that's as dumb as clauses get.

I'll try to get the legal team on it. It's a landmine as even a casual discussion of performance voids the license. Any discussion of outage may or may not involve this point.

It is a devops prevention clause.

> even a casual discussion of performance voids the license

Of course, that assumes such terms are enforceable. But, even if not, just having them in there is just so odious as to make one seek out other solutions.

Oh of course performance matters. But privacy? Atlassian's privacy policy is even worse.

Does that mean hackernews could be sued by Jira for allowing this thread to stay up (assuming they use Jira internally and signed the ToS)?

Do they define performance? This suggests you aren't supposed to discuss the Cloud Products with anyone. Can imagine if everyone follows this it won't be good for Word of mouth

That rubs me so much the wrong way.

If they ever terminated services for me because I commented on performance I would be the most loud person on the internet about it.

I would go to every review site, every comment board, and filter every title on every news aggregator and post as much statistics as I could about performance and issues that I had with it. Then I would state that they had terminated my services for commenting about it, with the proof.

I would be totally radicalised against them, it's absolutely insane that they even have this as a ToS, but if they ever enforced it I'm sure many people would salt the fucking earth.

I wonder why there's no clause forbidding to discuss the shortcomings of the ToS itself

These "Oracle clauses" really, really put me off using a product, or indeed anything from an organisation.

I totally understand that benchmarking is hard, but using legal means to silence anyone from talking about aspects of your product is just downright scummy.

Haha, in addition to all the BS in their terms of service, I had a delightful experience the other day where they argued tooth and nail that they aren't subject to CCPA deletion requests if they give your username away, and at this point I've just been stonewalled.

Just speculating, I bet they've decided a lawsuit would be cheaper than figuring out how their spaghetti code works to be able to safely delete a few fields.

Ha, this just reminded me that back in... 2009 or 2010, I tweeted something about being frustrated with JIRA and within an hour I had a message from someone at Atlassian warning me that I was in violation. I think I deleted the tweet, I wish I could go back and revisit it.

I've never agree to Atlassians terms of service, so I feel free to comment all I want. (Edit: I guess I don't use their cloud product, my employers stuff is all self-hosted, so maybe those terms don't even apply?)

source?

Wow, that sounds like the most communist thing I've ever read in a ToS

Broad ToSs and zero consumer rights are full laissez faire capitalism. So I would argue this is the most capitalist thing in a ToS.

Probably because you have absolutely no idea about what communism is.

Having used classic for years before the NG switch I'd say classic was more stable and faster. Now I have extra clicks and broken JS features to work around.

Still both are huge and so configurable that saying one is familiar with JIRA is like saying one is familiar with C++ or Microsoft Word. Which begs the question, familiar with which parts and what versions?

At my new job, the combination of Jira+Slack+Github is the most productive development support I've ever had. Of course, a company-level investment in process and a great PM and TPM help a lot :)

The JIRA hate is well deserved. I don’t think I can get past how slow it is compared to other offerings in the market (eg clubhouse). It’s UI is horrible and unintuitive. Search is difficult. Using it to track work is manual, it adds too much overhead.

I ask that you try clubhouse or another tool that has more modern UIs. You feel that JIRA next gen is great only compared to JIRA classic. Next gen is still years behind in UX.

I think that implementing a tool "like Jira, only fast" would be a quite interesting engineering challenge. With the amount of configurability which Jira allows, it is not easy to come up with something performant. Maybe a compilation-like approach would work.

Does anyone else find it pretty obnoxious that this site changes the window title back and forth between "Jira is a microcosm of what’s broken in software development" and "(1) New Message!"?

Is this a bug? Who thought this was a good idea?

That website is "a microcosm of what's broken" with websites.

Here is that content without that: https://beta.trimread.com/articles/32605

Lol yes! The fixed floating header, the pop-up modal after a few seconds, the long load time for text/image content...

I know. The bot sucks!!! Sorry... it's my fault. My boss, Dan the author, just yelled at me and I turned it off :-)

It's their little messaging thingy in the bottom right. You have to click the x to close the notification.

It's seriously obnoxious!

Also, as a side note, the whole article is written by a JIRA competitor. Totally not biased at all!

This website is packed with reader hostility. A chat bot to recommend articles to me? Really?

They're using Drift, the little chat widget in the bottom.

I've had to build out tracking on marketing sites and we had to add a redundant, canonical page title to every page since 3rd party tools like drift change the <title> tag in the HTML to say New Message!!!!!

They do it so if you migrate to a new tab it tries to annoy you into going back.

Jira is a workflow tool, which also means that most of the issues mentioned here, can be sorted out between the PM and devs on who the workflow should be, and what the rituals for updates should/could be. Jira is flexible enough to accomodate it (mostly). From a developer perspective, some of the points maybe valid, but not from PM perspective.

It would also help if we could get an idea of what the alternatives are, that are better

Edit: Also looks like marketing for the product, than a valid article on Jira pitfalls.

I'm using Jira, not a huge fan (mostly because it's slow, the cloud version at least) and there's some clunkyness BUT every time I looked for alternatives it was either too opiniated (like SCRUM or nothing) or had really poor integration with dev tools. The big advantage of Jira is that you can customise it quite a bit and it has a good set of integrations and APIs.

I'm still thinking of moving away at some point but haven't found any alternative...

Try clubhouse

After working on more than 20 green field projects over the 25+ years I've been a software engineer I can tell you that yes... all SDLC management tools suck at times, but also can be a great part of something very productive. It's how much they are tailored to the needs of the team and how practical their consumption is. I've been a part of projects where JIRA is a nightmare and part of projects where it is a blessing. Same goes for Trello, Asana, Confluence, "just github", etc.

I've also used JIRA where it is ONLY managed by the engineers and also when it is owned and managed by large teams of non-engineering stakeholders.

My 2-cents: When a project isn't going well it's the team that is deficient, not the software, in 99% of cases. Most of these tools can be customized (and combined with other tools if needed) to create something that works... and this varies on a project by project basis. It's not about the tool... it's about how pragmatic and adaptive a team can be as they apply them. Panaceas do not exist in this problem space.

Hi Sean here. I work on Jira at Atlassian and I also met with Justin and the Jira Admin for his company prior to this article. I've also heard from him since. He was not consulted re the use of his comments. Generally, I'd encourage vendors to seek permission when citing a customer in marketing in this way. It's a simple respect that can be paid with low effort.

I thought it might be helpful to share a few thoughts on the article. To do that I've added annotations on the article itself using Hypothes.is an open web annotation service. This lets us have a conversation right over the article. I've added a dozen or so comments, gifs and links to help add color from the Atlassian POV.

You can view my comments and add your own via this link or find me at @seanjregan on Twitter. https://hyp.is/go?url=https%3A%2F%2Fdzone.com%2Farticles%2Fj...

Usually we don't engage in the annual articles by competitors that pin SW industry failures on Jira but in this case it seems a lot of what we've been shipping in Jira Cloud is perhaps still unknown. (And, this annotation tool seemed well suited to this sort of dialog.)

Much respect to the LinearB team. Anyone working to make SW Development better is good in our book. Great products will stand out on their merits among the dev community.

While riding the Jira coat-tails via blog titles is a common approach to generating traffic, I want to also note that Atlassian is very open and we're happy to partner with any vendor that can make dev life smoother.

We partner with GitHub and GitLab as an example. If they can do a better job or a customer prefers their tools then it is on us to 1.) Support them and 2.) continue to up our game.

-@seanjregan Add your feedback, comments or Jira tips to the article here. https://hyp.is/go?url=https%3A%2F%2Fdzone.com%2Farticles%2Fj...

Hey Sean, Dan here and I wrote this blog post.

Thanks for the effort on the detailed response!

We have a core value at LinearB to empower the dev community and I can see you share a similar passion. The tone of my blog post came off more critical of Jira than intended and it’s great to see the improvements your team is making.

Although LinearB is not a Jira competitor, the issue remains that once story planning ends and coding begins, development teams are left with a major gap to stay up to date in real time to support the hundreds of micro decisions dev teams have to make every day. We are eager to address this problem!

It takes hyper correlation between Git and project management tools combined with a developer first mindset (not project management).

Since you are open to partnership, I will reach out to you so we can meet and pursue!

Thanks again Sean.

(I also responded with the annotation tool you used here: https://hyp.is/A_Sb1N2gEeq1_E8AuivgVQ/dzone.com/articles/jir...)

Insinuating anyone talking about you is riding your coattails doesn't show "much respect".

It would be more helpful to share your thoughts here.

I hate plenty of things about JIRA, but I'm flagging this post because it's incredibly biased (written by a direct competitor to JIRA), and their site is also extremely hostile to users with their messaging notifications.

Yeah it almost reads like a comparison piece. Pretty much all of the points relate back to the fact developers are adding manual updates and how the competitor solves it by integrating Git PRs and commits. However that's easily possible in JIRA now via the integrations (e.g. GitHub) and automations to close tickets depending on the status.

Still, even then with the automations in any of this software to show VCS updates you're going to get managers asking for updates depending on your environment.

At least Jira doesn't make popping noises and then show a banner ad that covers the entire page after 10 seconds.

Usually Jira sucks because it's not setup correctly to support teams' workflows, instead it's used to impose workflows on teams.

Jira can be as heavy or lightweight as you make it, but most of the suffering I see is because the way teams work isn't being supported by the Jira owners/admins.

Sounds like a microcosm of what's broken in software development.

Agreed. Jira exemplifies the “you’re holding it wrong” software.

exactly. if the process is broken, jira makes an easy scapegoat but that's misplaced. i've joined several teams (as PM) that hated jira until we were able to talk through the preferred workflow, and then reconfigure jira to support that workflow. then it was embraced, especially with automations that advanced tickets through the process where possible.

Agreed. I guess what make tickles my brain about it is that you can have a rather complex set of automation, integration etc. under the hood, while keeping the surface somewhat clean.

I used to think Jira was horrible. Then I moved to a company that uses Pivotal. Now I know what horrible means.

my feeling to this day is, to paraphrase Churchill, that Jira is the worst possible project management software, except for everything else.

I don't have a problem with Jira directly. It's not great, but I've yet to find a project manager that's amazing so I can't say it's substantially better or worse than the alternatives.

That said, I really don't want to work with a PM who loves Jira. It's so flexible and configurable that it seems to really call out to a certain type of PM who adores adding lots of process for the sake of itself. Can we make a 43 step workflow starting with "preliminarily claimed the task", "read the requirements sheet", "read the associated documentation", "opened an editor", "ran 'git pull'", "created a new branch", etc. etc. etc.? You bet we can! I've worked with PMs who really wanted that level of granular visibility into project status, even though it greatly slowed down the work of actually getting stuff done.

So in my experience, you have PMs who love Jira because it gives them a level of control that I absolutely don't want to be involved with, and PMs who think Jira is "eh - it's alright". Atlassian's problem with the latter is that they're just as likely to say "eh, Pivotal is alright too".

There needs to be a Heisenberg's Uncertainty Principle for software development: measuring a process is guaranteed to slow it down, so there's a spectrum between "fast chaos" and "corporate paralysis" that you have to consciously select for, and you don't get to pretend that "fast and tracked to the tiniest detail" is something that's possible.

(Side note: Confluence died for me the day a new version removed the option of editing page markup directly. Up until then, I had a workflow that converted Python module documentation to Confluence wiki markup and uploaded it. When that went away, I vowed never to use it again until it came back. Has it come back?)

At the company I currently work for, Jira has become yet another opportunity to engage in metrics abuse. Probably because Jira makes it easy to create reports and dashboards that are more useful for managers than for delivering software.

The company, which has "committed" itself to "embracing agile", has implemented some new employee performance policies which clearly demonstrate those decision makers don't know wtf agile is. One such policy is tying performance to "individual velocity" or story points per sprint per individual completed. Some managers, especially my current manager, care more about individual velocity than what velocity is supposed to be used for.

Consequently, developers can be raked over the coals if their individual velocity dips below a pre-determined number. When my manager confronted me with my lackluster individual velocity over the last few sprints (shown by a Jira report), I first tried to convince him that team velocity mattered more and that it was supposed to be a metric used for planning work for a sprint, not as a forecast metric. I tried to get him to see that velocity for everyone would improve when we got better at prioritizing and creating stories that allowed us to deliver value each sprint. It would also help too if we could function better as a team. But he wouldn't have any of that. I just had to improve my personal velocity.

So I learned how to use Jira better. I created pointed stories in the backlog I knew I could finish in a sprint and meet my forecasted velocity. The next time my manager ran his Jira report, he remarked on the improvement. The amount of work I actually did didn't change, but my individual velocity did.

While I agree with the premise of the OP about Jira. I would go even further than just Jira and say that today, proficiency and mastery of any tool used in the software development lifecycle seems to be more important than knowing how to do software development right.

> The current software delivery process revolves around pushing decisions down to dev teams and forcing engineers to push status updates back up. This system ensures executives are the only ones who have context and can see the bigger picture while engineers do all of the work.

> This is backwards. It holds us back from building the best product and slows us down from delivering faster.

Thats engineering. If you don't like it then try to make a career move into management or product or start your own company (not advised).

I myself had to come to terms with reality and have been making the transition.

You got one life, no use complaining until the day you die. Move into management and make the changes. If you're ambitious enough, you should have learned all you need to learn from engineering after 6 years and can apply your knowledge in a more strategic role, running circles around non-technical PMs.

> Thats engineering. ...

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.

> push context down, not decisions

whats the difference? either way the context or decision is defined by someone else, and you're still the one swinging the hammer.

I actually think there's a major problem in engineering where many don't take charge of their lives and want to guide the decisions. Its a weird Stockholm syndrome love-affair with being the engineer. Idealism is also a problem ("it doesn't have to be like that.").

> (most) of the devs much happier

yeah, but not the ambitious ones I was talking about.

I'm not knocking engineering, I'm saying it's a stepping stone in your career, and not a long term place if you want to influence trajectory within a company.

I briefly used Jira, but I couldn't handle the extreme slowness. You click something. Then you wait. And wait. And wait.

Cloud or Server? It seems a lot of companies’ reputation were broken by clients installing their software on 2GB/1.5GHz servers with HDD, and Cloud will help at least getting a consistent measurable experience of the same product for everyone.

In what universe is a few billion instructions per second not enough to respond to a single click?

In OSGi universe. Making software which does one thing well is the easy part. Making extensible software with plugins is super-hard.

It has been done many times over the last 25 years. I think that's a pretty thin rationalization to having a program freeze when you click a button.

We're running on the Cloud version and the ticket pages are incredibly janky and slow.

My personal pet peeve is the very short session time, after which you literally cannot use the form you filled, because someone was too lazy to implement a full session system to hold content or background relogin to not lose it.

Yeah. That part is bad and has somehow gotten worse. The animations don't help.

They have a MacOS app now, which I've been meaning to try.

The MacOS app is blazingly fast. But oh so buggy. It has the potential to make me not hate Jira but it's still a bit rough.

It doesn’t get any better

What seems to be lost on too many people - including people who really ought to know better - is that 90% of the time, software developers don't know exactly how to accomplish a task, but know how to figure out how. There are two classes of "estimates": "that will take a few minutes because I know exactly what's involved" and "I'm not even entirely sure exactly what's being asked for here, but it sort of 'feels like' this other thing that took about three days that one time before".

My struggles with Jira are more that the people who should be in charge of configuring it effectively and running it smoothly (team managers and PMs) often don't. I see a lot of stuff that's incredibly inconsistent and a lot of features that are used incorrectly (most prevalently using labels for EVERYTHING, usually using 4 different labels for the same purpose where say, a component or Epic would make more sense). Exacerbating that is that these ad hoc half workflows aren't communicated effectively, so the only people that understand the systems are their creators

Jira's complex, I get it, but lots of things are. Jira's docs are decent enough--certainly decent enough that following the tutorials will grant you an understanding of the various tools and their intended purpose--but people seemingly just don't read them. Some things just aren't going to be fully discoverable or clear through UX alone.

More galling is that these are usually the same people that then create shadow PM empires through Excel spreadsheets of their own design, which is just ugh. So much blame is heaped on Jira that's probably better blamed on ineffective management.

This, exactly. All complaints about JIRA boil down to poor administration, not the tool itself.

Learning Jira and accepting Jira both classic and NG has made me so much money, as a team leader, architect and program manager.

Jira is the user plane for interacting with project items, however like others here said, everything else must be solved with clear communication, frequent ACKs with team members and so on.

Yes, Jira Next Gen is nicer. But classic works fine too!

Also Jira can be a lot of other things. It's really flexible.

But at what expense? Does Jira ever frustrate you? Imagine how it frustrates developers that hate working with overly complex time-sink software. I can change my email client. I can change my text editor to my liking. I can change nearly any other tool I use, but when a company uses Jira, I'm trapped using something that mostly gets in my way.

I don't have the choice. I am just a cog in the wheels and it helps us do our job.

It's not really in the way, if that's the case it sounds like your processes or workflows are messed up.

I've had days where I don't want to see it, but that's because I'm tired of working. In those times it quick to blame Jira.

Oh definitely, the places I’ve worked have used Jira as a crutch for broken processes and workflows.

Well this was disappointing when it turns out this was an advertisement for what looks like clowns building the ultimate micromanaging platform, complete with profile pictures and little status tags and progress bars.

I really dislike using JIRA, I struggle with it for all the reasons there, and more. But...

"Though I think of Jira more like a spreadsheet. Very useful once upon a time. Outdated now. Static. Manual."

Are spreadsheets really outdated now?

I think the author has made the ever common mistake of confusing correlation and causation. Bad engineering orgs often use Jira, but Jira does not cause bad engineering orgs.

Anecdotally, the most frustrating company I ever worked for had obsessive Jira practices, but there was so much wrong with that company I could write a book about it.

> Take subtasks, for example. The invention of Jira subtasks is an affront to dev teams.

Really? Not to me, although I’m not clear when to make a subtask or start using an epic.

Generally subtasks are good when it's a single well defined feature or problem and then they are few. To be used sparingly. They're best used like keynotes.

Epics are for broad developments, looser defined. Best used as "bags" of tasks.

Sometimes epics might be disabled altogether and then you have only subtasks, and labels get to be misused as the bags of tasks. I personally consider that a pathological setup. It is much harder to work with and JIRA query tools don't work as well with it.

Nice blog post about your new platform I guess.

I do remember working on projects before Jira. My first job out of college managed their software dev lifecycle with Bugzilla. I assure you, it was much worse.

Jira isn't bad, it isn't great, and I honestly don't waste much thought thinking about how bad it is.

Jira is very customizable in how it's used. It's sort of like saying that a wall with sticky notes is a bad development tool because of some anecdotal experience. It all depends on what you do with it. Maybe it's more like saying that a spreadsheet is a bad tool.

The only thing I resent jira/confluence etc for is dropping its markdown because it was too hard for the company to maintain :) But they're working on it again. Confluence is probably one of my favorite tools but I haven't used jira in ages as it's possible to get by with github these days.

"This is the root of the issue. Jira was made with project managers and product managers in mind. Not dev teams. Project and product managers (collectively referred to as PMs going forward) are the primary buyers and owners of Jira. Not engineers.

Engineers love simplicity and efficiency. Jira is the polar opposite of that."

Why shouldn't project managers and product managers love efficiency, too? If the tools allows the engineers to do their work more efficiently, the development speeed of the team increases - this is what makes project managers and product managers look good.

Hm. To me it sounds like they are ranting about micro controlling by too much detail in the jira. Sure, if you have to close 6 tickets for the same line of thought, it's annoying. So don't do that.

And on top of that, the new jira automation + smart commits make stuff much smoother. Assign yourself a ticket, push some stuff with the ticket ID to auto-progress to <in progress>, commit something with "EXA-042 #close" and it auto-closes. Took us some time to get there, but now it's a smooth todo-list for the team.

To paraphrase many of the comments here: Most of the problems that devs have with Jira are not problems with base Jira, but with the implementation and usage of Jira.

Jira is perfectly fine, just like ALM is perfectly fine, TFS (Azure Devops?) is perfectly fine, Trello is perfectly fine, etc...

The problems come from the implementation, and the implementation is reflective of the culture. Any work planning tool becomes a work tracking tool and any work tracking tool becomes a punishment tool (without careful and attentive work to stop this effect).

It's not the fall that kills you, it's the sudden stop at the bottom.

It is perfectly reasonable to blame the agent of chaos for the chaos that results.

ehh, but this is kind of like blaming the results on hitting concrete vs hitting a cornfield. Yes, you might have a slightly less bad time hitting the cornfield, but the height of the drop is the more determining factor.

My point is that people love to let Atlassian off the hook. They set up the conditions for failure. You can't blame all of the consequences on the person who touches it last.

It's really the same class of externality that we used to blame Microsoft for. You can try to collect all the cash and all the fame and then blame stability and usability problems on third parties, but not everyone is going to buy it.

If you weren't pandering in the first place, you wouldn't have all that cash or fame. You knew what you were doing. Even if you don't want to say it out loud.

I've never understood the hatred for JIRA - it includes a ton of features that many find useful. Yeah it's a PM tool but you need the ability to organize boards and workflows at scale in larger organizations. It's not a tool intended for your startup that can manage with Trello or Github Projects.

This reads like the usual developer's opinion of "the world is not built for me" and "I don't like it if developers aren't thought of first"

It's not just a PM tool. There are hundreds of examples at our company where e.g. developers documented various tasks in Jira tickets including steps to take, commands to run, things to watch out for, that benefited me greatly. Sometimes the original developer is no longer at the company, and yet I can find the information in a ticket. Our Jira installation is more like a shared brain than a PM tool.

> So why do companies use a tool that works for a few PMs and business leaders when dozens or hundreds of engineers hate it?

In fact, Jira is so infinitely configurable it reflects the org chart and culture of the company using it. Most Jira complaints I hear are more about that person's company than the tool. That said, the tool definitely doesn't help as much as it should (largely because engineers don't make purchase decisions).

Never understood the Jira hate. It's very useful and infinitely better than email.

Well, I've been forced to use Jira for a decade or two now. Not a huge fan, but it is ok. Ties directly into gitlab, has a kanban-like board. Every used bugzilla?

But, I've never had any of these other complaints. When will this ticket get fixed? By the end of the sprint. I do tickets in order of priority. Rarely been a problem, so surprised to hear it brought up.

At my current gig, the PM has been there a decade and I only a year, so a great majority of the time I am asking/he is telling me how things should work at a high level. I value the advice.

I did work for one disaster project about ten years ago. Constantly interrupted for fires, tens of hours of meetings per week, and rarely finished sprints. We were overloaded on tickets because sprint planning never took interruptions/meetings/bugfixes into account. We used bugzilla there, but it wasn't the culprit.

Annoyances: just thought of one. The issue page has a ton of stuff I don't care about and de-emphasizes the comments which I'm most focused on. I also don't like how when you click on things it switches to edit mode.

Jira lost its usefulness around 2014. It became much too cumbersome to use, and Atlassian‘s help documentation was/is? out of date. We asked for training, something more than poorly written documentation, and we were quoted an exorbitant price for that training. That was the straw that broke the back and we left Atlassian for good in late 2015 and never looked back.

While you do have some valid points, especially when it comes to friction between PM/Devs, the way you seem to be using Jira seems to be the polar opposite of what I have experienced.

Granted, I don't have an overwhelming amount of experience working at different companies, but I feel like the Devs in my company were actually the ones that wanted to use Jira for customization options.

Intriguing!

I like jira. Our installation is pretty fast and I need something to track what is outstanding. The query interface is quite powerful, and I can use it to gather evidence that something needs more attention. It's got too many fields but you can turn these off, unfortunately for my org that requires IT so I live with its current configuration.

> Jira was made with project managers and product managers in mind

A step further, SCRUM was made for product managers in mind. Engineer-centric Agile methodologies like Extreme Programming are missing from SCRUM guidelines.

Most product management methodologies have a bring-your-own-engineering-practices philosophy, which means they were created in a vacuum.

JIRA is just a tool. A pretty reasonable one. It integrates with every dev tool under the sun at this point. It’s as lightweight, or invasive, as you want it to be.

Sometimes there’s people or workflow problems that get blasted as jira (or rally/ac) problems because that’s the interface you see those people or workflow problems through.

Nah, generally the point 1 stands. JIRA has potent top down customization tools that are easy to misuse, e.g. adding required fields, task types priorities or defining task flow.

Just that information overload can make working with it a real pain.

These can easily break its own features e.g. scrum or kanban boards or backlogs, which are configured separately.

And the dev or project lead typically does not have access to directly customize it, because JIRA ACLs are way too broad or company has a top down policy on it.

On top of that, it has rather weak support for default values...

Email notifications are also not exactly customizable by the user. It's worse at that front than bugzilla even.

One thing that was sort of customizable are the frontend report views. Shows for whom the app is made - beancounters.

Every single project I've been on in the past 15 years (public/private sector, many verticals, different companies), when push comes to shove, people resort to tracking everything on simple spreadsheets or punch lists. And it works just fine (although this results in more communication which is anyway true when things go wrong or overdue, regardless of tools).

So I'm really wondering how much utility a lot of these tools bring (I LOVED Jira in 2006 when it was a glorified table with powerful filters, but I was using it roughly like a smart spreadsheet). I feel a lot of what they add is just busy work that you have the luxury to play with in normal times, but when you don't have the luxury to do busy work, it just slows you down without much benefit.

What have other people's experiences been? An emergency can be a great filter to show you what matters and what doesn't.

There is perfectly common sense solution to every issue OP has raised. I have used JIRA for 7 years in many different teams and I think it works and does not get in my way as a developer. In my experience the people who seem to have trouble with JIRA are the same people who have trouble with basic software engineering processes and being organized.

"Bosses (managers) get stuff done through meetings – changing tasks every 60 minutes." -- I don't know what bosses you are or have worked with but incompetent leadership and poor software engineering acumen can't be solved with buying software subscriptions.

Why are you trying to make for the tool being bad when the blame lies with people? I am tired with hearing this bogus notion of friction between Bosses, PM, Engineers and somehow you can pay your way out of lack of alignment in an organization.

Shots fired! It's true though. Using Jira is a struggle.

I started tolerating it after discovering it has keyboard shortcuts. Try pressing <shift>+? to see what's available in given context.

+ Make sure you have it bookmarked as search engine. Also makes it so much nicer when you can jump to specific ticket by using 'j FOO-123' from address bar. Or 'j whatever keywords' to do regular search.

I like the dot shortcut - press “.” and start typing a command.

Having been away from development tools for fintechs for a while I went back to my trusted Jira tool to find it incomprehensible. I also tried & quickly hated Teams & even current Slack. My new go-to tool that anyone in our org or from partners can use immediately is AirSend.io.

The attitude embodied in this is unfortunately common. Delivering a successful product is a lot more than just writing code and shipping features. Planning so that you can launch your marketing efforts, ensuring you have a team ready to support whatever you just shipped, or making sure you don't sign new deals that result in 6 months of work needing to get delivered in the next 2 months are all just as important to the business as the day to day work the developers do. Sometimes being a team player means you are a less effective so that other people are more effective. Jira isn't a perfect tool, but the case would be better made by someone who isn't myopically focused on optimizing a subset of the whole product delivery process.

I'm definitely feeling this today. I'm effectively locked out of jira today because the new versions of Chrome and FF block cookies that are "SameSite=None" without "Secure", and all of Jira's cookies appear to have this problem.

I think the post hit the nail on the head with the question paraphrasing „Why do companies buy project management software that only project managers love But engineers hate?“ The answer is project managers manage projects so need project management software.

My company uses Jira as our primary tool for development and we really like it’s simplicity and effectiveness. With integration with Bitbucket, Trello and Pipeline our developers find it easy to work with. Jira is also easy for non-technical team.

The JS-heavy web interface of Jira can be infuriatingly slow, so perhaps the frustrations start from there.

Jira, the project management tool, can actually be great, if you configure it properly. The issue lifecycles, what fields are visible, how the board is showing things etc. can be designed to be as simple or as complex as you want it to be. In addition to that, the integration with Bitbucket and Confluence is also fantastic for referencing issues and features across the code and documentation.

Misuse of a tool does not make it a bad tool.

Disclaimer: have worked on developing a Jira plugin, so my understanding of Jira might be a bit more advanced than that of a novice user (but not by much).

> if you configure it properly

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 decision<=>development 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

Sorry everyone on the bot. Just yelled at our marketing people to turn it off.

I personally found the main criticisms to be insightful reasons why Jira doesn't really add much value to a workflow, but most problems can be dealt with by taking those issues into account and continuing to use Jira. Then again, I'm not entirely convinced tools like Jira are ultimately much better than just managing with email and whiteboarding, which is probably why I feel so meh about it. Everything it does just feels unnecessary 99% of the time.

I feel like half of my bosses don't understand what goes in to my teams process for new features. They're probably the ones that bought Jira in the first place.

Jira totally removes the fluidity in the software development process, I've stopped using it altogether and now rely on Google Docs and Sheets.

That site is annoying. Popups. Fake "notifications".

As a bug tracker, JIRA seems to be OK. As a development system, not clear.

Sorry! We know the bot sucks and we just turned it off. Lame marketing people.

The problem with Jira is that a lot of useful features are only available as plugins. But your company won't pay for any of these plugins, or they simply don't want to maintain and install them for security reasons.

So you are stuck with the basic Jira version you company pays for and will never see any of the nice extensions that are available for it.

Jira does have an extensive and documented API. They have e.g. an official integration / "client" for VSCode. There is a couple of CLI tools.

I hope more alternative frontends will eventually come up to address the UI issues, to streamline particular kinds of usage, etc.

This can't address the API speed, though.

You dont appreciate Jira till you no longer have Jira.

Depends. I worked using Fogbugz and Trello on different projects and it was a blast in comparison. And another unnamed homebrew which had warts but was still better than overloaded JIRA in some other projects.

Then again I've worked on the project where the source of truth was a set of Excel documents shadowing 5 different ticket systems. Very briefly.

That said if you're lucky, JIRA can be set up to work relatively well. Especially if you keep it simple.

I've noticed that more people complain intensely about stuff that's not going away - Jira, Spreadsheets, Twitter...

yeah, there are a couple of up-and-coming tools that try to correlate product spec to tickets while maintaining a separation between the two

hard problems like spec, estimation of work, and assignment of work to people are conflated in a ticketing-only universe

Interesting. Can you drop some links to your favorites?

haven't used any so wouldn't endorse, but the general category is 'roadmap' tools or what used to be called 'idea management'

there are some 'release management' or 'launch management' plugins for JIRA that address the other side of the pipeline, but solve similar problems -- also haven't used, but friends who are big-company PMs talk about them

IMO many saas products are inflexible, their strength ('we automate workflows') is also a weakness ('better not deviate from these workflows')

The only project management tool I've heard people rave about is airtable, which is basically an improved spreadsheet UX and not purpose-built for project management.

I suspect the future of project management saas is tools / plugins that provide summary views, but the tickets / specs exist in freeform spreadsheets like airtable. This 'view plugin' ecosystem is alread starting to exist for notion and roam.

I wonder if JIRA uses JIRA to track itself

Of course it does. For a while, external people could even log the issues themselves.

Having used it, I don’t understand all the hate. I love the Sprint boards, the drag and drop and the JQL. Of course I deactivate everything that tries to help me, it’s kind of like Clippy: they « make it easier for you » by hiding all the fields, or opening an issue by hiding the search table. Would be easier to understand if Jira only had 3 screens: Issue view, Search and Sprint board...

It does https://jira.atlassian.com/projects/JSWCLOUD/issues/JSWCLOUD...

I can confirm we do.

Just use Basecamp

Yes. I remember the first time I encountered Jira, I assumed we would just login and start created cards and tasks etc.

Except the first meeting we were introduced to a "consultant" who needed to "design" our process flow before we could do anything.

I went back to Trac needless to say.

I think the problem is that Atlassian has designed their tools for information hiding.

I may not agree with Larry Wall on much, but he is credited with one of my favorite aphorisms:

Easy things should be easy, and hard things should be possible.

You can't pre-filter complexity for developers. That's our job. We have to know that there features available even if they have been turned off. Otherwise we're going to blame the tool for skimping on functionality. And we are perfectly right too, because how the fuck are we supposed to know that Bamboo has a feature if the button only shows up for full administrators?

Of course we're going to bag on it. And they deserve every bit of it.

Reply on news.ycombinator.com