22 ms·

JIRA is an antipattern

• dboreham 8y ago
  I've yet to see a bug system that is anything close to as good ss Bugzilla was in 1998.
  • hmottestad 8y ago
    What was good with Bugzilla that you miss from the likes of Jira?
    • achamayou 8y ago
      The good thing about Bugzilla was that it was clearly a bug tracking system (and it was excellent at that), whereas Jira is only a passable bug tracking system pretending to be a project management tool.
      • hmottestad 8y ago
        Can you be more specific? What is missing I've used Jira for quite a few years at work, and the number one issue with Jira that I have found (and also my team) is that bugs that don't get fixed tend to get lost in the mass of everything registered in Jira. Jira does try to both be a place to register bugs (and features and other tasks) while also trying to be a place where you organise how the work should be done (eg. with sprints). I guess Bugzilla doesn't do that?
        • achamayou 8y ago
          A good bug entry is (completely) unlike a project planning entry. It comes with detailed environment and repro instructions, artefacts such as logs and screenshots. It’s an investigation, not an item in a wish list, and it’s ideally a place where every dev in the team can chip in and offer additional data or suggestions. If it isn’t used to track progress or productivity, it contains exactly the right number of entries (since there is no incentive to the contrary). The criteria for closing a ticket are very clear, there is no risk to offend someone by closing their half implemented and ultimately insufficiently detailed entry for example. Bugs are either open or fixed! The tool does not figure out who should be fixing which bug, that’s the job of the team lead. When an issue falls on the fence between a feature request and a bug, whoever is allowed to make the call needs to decide and either keep it as a bug, or mark it as wontfix (either out of scope, or to be looked into as a feature). A well maintained bug tracker is valuable to users, because it comes with a good search implementation (Jira’s search is abysmal for error messages!), and then can work if and when the problem they hit has been fixed. Cluttering that with project management does not help!
      • alkonaut 8y ago
        But is it really that useful to track bugs separate from other work? I find that most often it's even hard to agree what IS a bug and what isn't. There is just "work".
        • achamayou 8y ago
          A bug is a difference between the intended behaviour of the code and what it actually does! If you regularly can’t decide what tickets are, then you must be working on something that is especially under-defined and under-documented. I would suggest addressing that, and that Jira is not going to help you there.
          • alkonaut 8y ago
            I think the reality is that software is very rarely specified enough that you can go to a central specification and point at it and say "look here in the spec it says it should do X" Something unforseen is occurring that the spec never talked about and that's reality. (trivial example: if you design without full unicode support you don't explicily SAY in a specification that you aren't supporting some characters, nor would you say you DON'T support such characters). And then a customer comes and says his name shows up as gibberish and you have no tests and no spec mentioning whether this is expected or not. It's simply a case that no one had thought of in neither specification nor implementation. The fact that it wasn't specified makes it easy to say "since we didn't expicitly mention it, it must be a bug". It's in my experience usually futile to point fingers towards whether something is a bug or a new feature in this case. The customer obviously doesn't care, to him it's just a bug even if it's a lack of a feature (because the customer doesn't have the specification even if one exists). So to the end user it's very much a bug even if to the development team that may have written a spec that says "it shall be iso8859 and garble any utf-8" it is a completely new feature! And even in the latter case where even the buggy behavior was well-specified, you'd be having a bug report describing the garbled text as a bug. The best you can hope for in a dual bug/feature system is to close the bug report as *wontfix - by design - see feature 123 in the feature tracker 'add unicode support'". This may be a trivial and perhaps obvious example, in most cases these realizations may take a large portion of the time. Now: a public facing bug-report system feeding into a separate bugs-only-tracker can certainly be useful still, but once those end-user bug reports are converted into work, whether it turns into a workitem in a separate system marked "bug" or one that is marked "feature" isn't really that important. Work has to be prioritized in the same queue anyway. The ROI for fixing a bug, specified or not, has to be weighed against the ROI of adding a feature.
      • PretzelFisch 8y ago
        What made it a good bug tracker? I still use it and find may design choices like not being able to edit a bug or comment frustrating. Also the lack of some basic formatting in the bug descriptions.
    • yxhuvud 8y ago
      Being able to specify arbitrary amount of levels of dependencies. Ability to have multiple cards depend on the same subfeature.
  • itomato 8y ago
    Is it that Bugzilla was good or that Sweng was out of the Executives' field of view?
• tomohawk 8y ago
  This is absolutely correct. I've seen the analogy of the city build-out occur again and again as teams become fixated on tickets instead of understanding the overall problem and architecture.
• itomato 8y ago
  Flawed premise as Jira Software is not Jira and the Portfolio app addresses their main complaint. Junk article. They also point out that Jira is no longer in all caps but couldn't be bothered to search and replace.
• CoolGuySteve 8y ago
  Apple has a system called Radar that treats everything like a ticket. Projects are tracked completely from Radar. Considering Apple manages to ship pretty decent software, I don't think blaming your tools is really appropriate. The only real difference from Jira was that despite coming from the Carbon era of design, Radar was much nicer to use because, as a native application, it showed tickets in a regular table view where you could multi-select, drag and drop, etc. I personally find Jira miles more confusing than Radar after having used both extensively. But that's a fairly minor difference, the design paradigm was the same.
  • tonyedgecombe 8y ago
    Culture trumps everything. If management are using tools and methodologies to micromanage their staff then they will never get good results from them.
  • Cymen 8y ago
    There have been at least a couple of posts here that had thread discussion about this approach at Apple leading the focus to be on features over bugs. That things don't get fixed. Before holding Apple up as an example of good, best to look into those as those complaints/comments here mirror things I've seen on other venues in terms of features versus working software being shipped by Apple.
    • hellofunk 8y ago
      And yet, compared to, say, Microsoft, are their bugs any worse or more intrusive? Apple's software has at least been relatively stable for a long time. That is not a track record Microsoft has.
      • bunderbunder 8y ago
        With Microsoft, I'd say it depends wildly on the team. I've known .NET to be rock solid stable. Similar for Visual Studio - most Visual Studio bugs I've experienced turned out to be ones that JetBrains was injecting through the plugin API. Office, too, is a pretty well-turned piece of software, especially considering its size and age. It's largely the Windows team that has a hard time getting its act together.
• hn_throwaway_99 8y ago
  I expected to read this as a "Ah yes, another JIRA bashing article." I've tended to view JIRA as "the worst of all project tracking tools, except for all the other ones" so I like to rise to its defense when I see folks complaining about it without taking into consideration the needs of other stakeholders. That said, I've found myself agreeing with pretty much everything in this article. While I believe that JIRA (if properly configured) can serve as a good issue tracking system, attempts to do top-down, high level planning on it have always left me with nothing but frustration. My advice would be to completely ignore any of these features (e.g. all the "portfolio" add-ons), do high-level planning down to the epic-level in something else like Excel, and then map that to tickets in JIRA. The "Nirvana" of having complete visibility from very high, enterprise executive level planning down to the "what am I as an individual developer working on today" level in one tool is a false idol and just not possible.
  • sb8244 8y ago
    Asking seriously: is it that it's not possible with today's tools, or philosophically not possible?
    • throwaway9471 8y ago
      My manager had a rule, that each member of the team was only allowed to have one unresolved ticket at the end of day. We had a weekly meeting where we would be badgered about every >1 unresolved ticket and had to come up with an action plan to make sure it never happened again. So coincidentally, we would "forget" to create a ticket for every issue, that would take more than a day, until it was one day from completion.
      • praptak 8y ago
        I do sometimes follow this rule. Caveat: it requires unassigninig tickets that I'm not actually working on. It makes some people cringe in horror but once you start doing that it does wonders.
        • 8y ago
• lmm 8y ago
  Wow. I hate JIRA but this article gets it completely backwards. Having small-scale tickets that you actually finish is the very essence of agile - limiting work in progress, defining "what done looks like" in a customer-facing way for tasks that each last at most two weeks. Ignoring the "wider vision" is the best way to produce software that actually solves people's problems instead of beautiful n-tier architecture that doesn't do anything anyone wanted. JIRA is heavy and slow - it's model of limited transitions is fundamentally flawed, encouraging micromanagement and making mistakes hard to undo. But a lightweight board that you push tickets through - the famous "kanban" - is a great way to develop software (I've had a lot of success with Trello, though I fear it's only a matter of time before Atlassian bloats it into JIRAness).
  • jimnotgym 8y ago
    I agree with you about Trello, but even better than that is paper-cards on a wall. Trello adds unlimited wall space and a distributed wall. If you don't have lots of remote workers, and the wall is big enough, then use it. There is something wonderfully tactile about chatting in front of a real kanban wall when working out priorities. At the next checkpoint/sprint meeting, you can physically add cards to your backlog. Physically push things up the priority list. I love it! I like 5×3 index cards better than post-it notes..
    • KaiserPro 8y ago
      The problem with trello is linking tickets intelligently is hard. The concept of epic/subtasks is missing. So if a ticket becomes to big, and you want to keep the history while breaking it up, requires a boat load of copy/paste. Also, there is a trend to have a physical board with tickets, as well as a trello board. This was fashionable amongst the scrum masters at previous large employer. It was universally hates as we had to spend loads of time playing with physical cards, then try and copy the state into the ticketing system. Its was annoying and a massive waste of time for everyone. Especially as it didn't encourage people to write the work they've done on the ticket, to allow it to be taken up by someone new.
      • 8y ago
• jimnotgym 8y ago
  I'm not going to defend Jira, but don't you just need to break down each ticket into smaller ones. To use their metaphor. The airport gets a ticket. Then you put another ticket up that says 'find a good field to land in', then another that says 'level out field for x class of plane', then another that says 'install basic lights'etc. Things are now getting marked complete and you are agile all over again.
  • iainmerrick 8y ago
    That sounds good but (as far as I know) Jira hard-codes the number of levels, so you quickly hit a point where you can’t break tasks down any further.
    • jimnotgym 8y ago
      Presuming you are letting Jira decide there is a logical link, I suppose. You don't have to, do you? I must admit I haven't used it an awful lot, but maybe this is one of those traps that you use the functionality because it is there, even if it is not useful. In this example you could for instance create 'Airport' as an task and just write on it that you are going to aim for a dirt strip first and are going to start a separate task for this. This is the power and weakness of Trello, there is no link! Except of course you can create a new board called 'dirt-strip'
      • iainmerrick 8y ago
        Well, I’d like the tool to display the levels in a useful way, sure. Even just nested bullet points would be okay.
  • rabidrat 8y ago
    What if that turns out to be an inefficient (poorly-architected) way to break it down? But it's half-implemented by the time someone calls attention to it, and it doesn't get re-architected because it's too late now. Breaking things down appropriately is, in my mind, 80% of the work. If you have your head straight, the implementation is easy; but it can take implementing virtually the entire thing to get your head straight.
• Cyclone_ 8y ago
  Jira has always been very quick and responsive for me. It offers a good amount of customization too, we have a custom workflow that makes sense for how we develop software. I've never felt that jira has been a limiting factor of what the teams I've been on have wanted to do with our workflow. Never once encountered a major bug in it either.
  • iainmerrick 8y ago
    It’s infuriatingly slow for me. Is this a configuration thing? Are our teams doing something different? It seems to me that it’s slow on a number of levels. It just takes a long time to load each page, and on top of that, basic operations usually take far too many clicks. So I figured it was just a bad tool.
    • itomato 8y ago
      Cloud performance is poor. OOTB Server install isn't a silver bullet nor is Data center. It's a spawling Java app with hundreds of discrete components, aging plugin architecture and is susceptible to configuration creep.
      • Cyclone_ 8y ago
        Yeah running it on premise should be faster.
    • perlgeek 8y ago
      The more fields you configure, the slower it gets. (That seems to be my impression, at least).
    • mxschumacher 8y ago
      same for me. ~7s load times on a 100 Mbs connection with a new macbook pro are a daily encounter.
    • slider_thor 8y ago
      Jira Cloud & Jira Server (on-premise) are two different beasts. I can speak for on-premise only. On my on-premise system which is located on the other coast of the country, a ticket loads in 1.5 ~ 2.5 seconds once your assets are cached at least once by your browser. Things I've seen that can adversely affect your speed: installing random plugins that are poorly written, integrations, having too many admins over-complicating the Jira configuration. Learn the keyboard shortcuts to speed up your basic operations.
• jasode 8y ago
  >But you need something else for the macro. [...] Allow me to propose something shocking and revolutionary: prose. [...] But it is a tool deeply ill-suited to be the map of a project’s overall vision or infrastructure, and it is never the source of truth — the source of truth is always the running code. I'm not sure what Jon Evans means by "prose" to document the "macro vision"... a freeform text file? MS Word doc? Personally, I need more structure than that so I use a spreadsheet for it. I like to create columns of metadata to assign a priority, notes about difficulty, estimated time, estimated cost, etc. Any large project will have hundreds of wishlist features that need to be organized. Prose is too unstructured for that. Maybe JIRA is too bureaucratic and the wrong tool too; I'm not familiar with its goal-planning tools. I can't store the "macro vision" directly in source code because many wishlist goals are greater in scope than placing a commented out line in a cpp file such as "//TODO:implement voice recognition." Yes, the source code is a "source of truth" but it's only truthful at the abstraction level of generating an executable. It's the wrong abstraction for gathering wishlists, future goals, and priorities.
  • geocar 8y ago
    > I'm not sure what Jon Evans means by "prose" to document the "macro vision"... a freeform text file? MS Word doc? Yes. Sometimes. > Personally, I need more structure than that so I use a spreadsheet for it. I like to create columns of metadata to assign a priority, notes about difficulty, estimated time, estimated cost, etc. I think having a spreadsheet is good too. This isn't either/or. > Yes, the source code is a "source of truth" but it's only truthful at the abstraction level of generating an executable. It's the wrong abstraction for gathering wishlists and future goals and priorities. I don't think that's what is meant by this statement: the source of truth is always the running code. I read it a call for an iterative and evolving "design" that comes from the program as it is run, instead of some repository of code or tickets.
    • jasode 8y ago
      >This isn't either/or. To engage with JE's particular essay, I think it is either /or. He emphasized "prose" with italics. Seems a reasonable interpretation is that he thinks the rigid or incorrect structure in Jira is wrong to document a macro vision. If he thinks another structured tool like MS Excel or MS Project is a desirable alternative, it seems he would have mentioned it. Instead, he recommends prose. To be pedantic, one can type "prose" right into Jira. But that would be an uncharitable reading of his essay. Therefore, he must mean something else: a document that's more freeform. >I read it a call for an iterative and evolving "design" that comes from the program as it is run If he meant that, he's wrong because the running program is always an incomplete picture of what you desire the program to do. The "desires, goals, and design" -- ultimately has to be stored outside of the source code and therefore, it can't be a source of truth for that type of macro vision. (Yes, there is a school of thought that proposes that "the source code _is_ the design" but I've always seen that as more of a reaction to UML diagrams and flowcharts from CASE tools that get out of sync with the actual code. To really fulfill the "code is design", it would require an extremely powerful declarative language compiler that turns high-level English specifications into executable code. Using today's primitive languages such as cpp and h files isn't a good way to express "code is design".)
• mooreds 8y ago
  We are looking at planning tools (digital agency, many clients with needs that rise and fall, small team of developers). We would love to have a time based resource planning view. Weren't really considering jira, but would love to hear any suggestions.
  • tdrgabi 8y ago
    How about a Gantt chart? It's a time based resource planner.
• leowoo91 8y ago
  Isn't that the fact most products get bloated over time, especially when funded in wrong ways?
• deleted 8y ago
  [deleted]
• rsyring 8y ago
  This article makes some really good points about the importance of knowing the larger project and infrastructure context when digging into details of a software project to fix bugs or add features. And, I'm not a fan of Jira. But, the difficulties noted in the article feel wrongly assigned to Jira. They aren't Jira's fault. It's a process problem of the org using Jira. A deficiency in the way projects are architected, documented, and communicated about. It's not the tool itself that is the problem.
  • erikpukinskis 8y ago
    You’re mistaken that there is a single attribution to “the problem”. Tools and process work together to create a production system. When the system fails both share blame.
• perlgeek 8y ago
  > And so people take tickets, implement them as written, pass them off to whoever is next in the workflow, consider their job well done, even if working on scattered groups of them in parallel might be much more effective … and without ever considering the larger goal. “Implement the Upload button” says the ticket; so that is all that is done. The ticket does not explain that the larger goal of the Upload button is to let users back up their work. Jira was designed for agile software development like Scrum, so you should write user stories, not mini specifications. An upload button alone is no user story, a story might be "As a user, I want to be able to import the Excel reports that I get from company $XY, so that I don't have to manually enter the data, and save a lot of time that way", ideally including a reason why that data needs to be there. That way, you get the context that the article is bemoaning the lack of, and the developer might even think "Hey, I know company $XY has an API for getting the report data, wouldn't it be even easier if we fetched it directly?" And in a good agile process, you'd discuss this with the product owner, and rewrite the story to "As a user, I want data from $XY company in my system with minimal effort" or something like that. No tool can substitute a good development process, and good communication between the involved parties. That said, Jira does have it downsides, and not tracking dependencies very well is one of them. And then there are things that can be downsides, but don't need to be. It's so flexible that many shops configure it to be pretty much unusable, but others create workflows that work very well.
  • hellofunk 8y ago
    >"As a user, I want to be able to import the Excel reports that I get from company $XY, so that I don't have to manually enter the data, and save a lot of time that way", This is a more general user story than I've seen when I've worked in agile developments. Usually, the stories are quite specific, like "As a user, I can click an Upload button to provide an Excel report."
    • mcbutterbunz 8y ago
      I agree. Usually the stories I've seen written are very implementation specific rather than an expression of the desired state. I believe its because its easier to think about concrete solutions. This goes for product owners and devs alike.
• KaiserPro 8y ago
  sigh The author uses a flawed analogy to push a flawed argument. Jira is a tool to track what stuff needs to be done. Using the author's city analogy, they appear to be advocating that all city workers need to have a vision of the whole city plan for any task they they are doing, that doesn't scale. Large projects are to big to fit all the detail in one person's head. Design goals are broken up, issued to specialist teams, which then break them up again. To then blame the tool for worker not bothering to understand what they are working on is not the fault of the tool, its the fault of the worker. Ok smart arse, how do _you_ use Jira then? Simple, its a big arsed multidimensional to-do list. There are a set of business goals with solid business deliverables(which of course translates into vague tech targets) Each team is assigned high level tasks. Its up to them to split them up and write down _what_ they want to do, and then in small subtasks _how_ they are doing it. if they are too stupid to ask "how does this align the business need?" then they shouldn't be allowed grown-up scissors. (why are you hiring them?)
  • steve_taylor 8y ago
    > Using the author's city analogy, they appear to be advocating that all city workers need to have a vision of the whole city plan for any task they they are doing, that doesn't scale. For most projects, it does scale. The problem with almost all software development analogies is that they attempt to draw parallels between design and manufacturing. Software development is much more design than manufacturing. A more suitable analogy would be art. Imagine a group of artists commissioned to create a painting. The designers decide, upfront, the main elements of the painting, then someone else breaks the work down into tickets based on those elements. Unless extremely well managed, the result is likely to be hideous and the project is likely to have a high turnover of artists. This is pretty much what happens in most software projects. The real problem, as this article identified, is that a bigger picture perspective is needed. Unless a project is crystal clear about the big picture, everyone will have their own big picture and build features accordingly.
    • TeMPOraL 8y ago
      > The problem with almost all software development analogies is that they attempt to draw parallels between design and manufacturing. Software development is much more design than manufacturing. Also construction. The way I see it, what programmers do is not constructing a building, they're doing the architecture (and wiring plans, and landscape plans). Construction is what compilers do.
• mjpuser 8y ago
  JIRA is meant to break up work. Atlassian has another product called confluence to let you write prose, like the author wants, and you can link all these things together. When you have a group of 3 people on your team, you need to coordinate different parts of the feature into separate tasks for each developer so that they can work in parallel. This guy/girl hasn't discovered anything we don't already know.
• deleted 8y ago
  [deleted]
• catchmeifyoucan 8y ago
  I find Azure Devops (VSTS) to be just as poorly designed for this purpose of macro design. Work isn't a linear process.
  • alkonaut 8y ago
    VSTS and Jira are two implementations of the same thing really. They are the two large enterprisey issue management suites. They are "the worst except for all the others". If you really are a huge enterprisey team that has many levels of visibility for various management levels and stakeholders, as well as large distributed teams working with different schedules and modules, then github tags or post-it notes eventually won't cut it. They are nice and streamlined for a while, but then someone will ask for a weekly report of X or a website showing progress Y and a corollary to my main argument is that someone is always to oblige with the request even though the correct answer may be "no! Let us just use streamlined tools and just make smaller independent teams!". And in the end if you start off with post-its, the github issue tracker or some lightweight issue management system you'll end up according to this theorem: Every software project management system in a large enterprise environment that isn't already a large enterprise one (like Jira), will eventually become an ad-hoc, informally-specified implementation of Jira.
• beefhash 8y ago
  It is, however, not a new antipattern. This kind of thing has been around since the 80s or at the very least since the POSIX standardization of SCCS. Even SCCS supported something called "modification request" numbers. These could optionally be checked by an external executable, tracing each commit back to a ticket number.
• diiq 8y ago
  I use vistimo.com for tracking what I build for clients; I built it specifically to alleviate the harm of the linear backlog, and help everyone share the same broad vision of where we're going, how long it will take, and what's changed about the plan. Storymapping isn't a perfect tool for sharing product vision, and by trying to be storymapping+estimation+progress tracking, Vistimo is of course imperfect at each of those things individually; but having the combination has done me and my clients a lot of good.
• kaio 8y ago
  That article is really awfull in expressing the root cause of the authors unhappiness with agile and enterprise scrum. Jira is just a tool. To stick with bad anaologies: how can a screwdriver be an antipattern?
• haglin 8y ago
  It depends on how you use it. You can create a design ticket where you describe the larger overall picture (city planning) and then as you implement it, add enhancements (neighbourhoods and sewers) as subtasks. If something breaks when you add the enhancement, for example a memory leak when calling method X, you can create a bug ticket that only concerns the micro details.
• kovrik 8y ago
  In my experience, the problem is always in people, not tools. Nowadays, Agile/Scrum is a buzz word, every company is trying to get it, but rare people understand it. They buy tools (like JIRA), they do standups, they assign story points...and then things become messy and it all turns into into a glorified waterfally kanban with story points. JIRA is just a tool (bloated, maybe), nothing wrong with it. Personally, I find it to be OK -- no major complaints about it.
  • lugg 8y ago
    I did a planning meeting while working remotely. The only thing that came out of it was a big word document that looked like the big word docs id write for waterfall back in the day. I don't think people realise just how little things like JIRA and Trello do for you. The only thing they can give you is a different view of that same word document. The second they over clutter themselves with junk in the interface and custom flows the benefit to using them is lost. Trello is a good example, it used to be pretty decent. Now it takes something like 10 clicks to delete a card. The rest of their interface is chock full of antipatterns like that. Someone needs to build something that does one thing well and doesn't try to do every other thing under the sun.
  • wutbrodo 8y ago
    I used to feel this way, but found it to be an unproductive model until I realized something: sure, most people are kinda stupid and sufficiently intelligent people can make many tools work for them. But most people's actions are driven _very_ heavily by their tools, and from a pragmatic perspective, criticizing tooling that drives bad actions for the average engineer makes a lot of sense. As an example: I recently ran a small engineering org (started out with just me, grew to about ten eng) working on a Python system. The founders had a lot of trouble sourcing, so we ended up with engineers that ranged from okay to mediocre to terrible. There's a ton of dangerous Python footguns that competent engineers have the discipline to avoid; engineering in Python at Google isn't exactly fun, but it's workable. OTOH, trying to run an engineering system in Python with the kind of engineers at this last company is a constant nightmare of catching and stopping idiotic abuses of Python's flexibility. Using something like Java would have imposed discipline on this engineers for a subset of the mistakes they were making. While it's true that sufficiently skilled engineers would've been aware of Python's pitfalls and worked around them, it's entirely fair to say that this permissiveness is a downside of engineering systems in Python. As another example, I feel exactly the same way about Facebook: for all the talk about how usage makes you depressed and scrolling through the newsfeed is bad for your mental health, I'm able to use it as a messaging, photo sharing, and event planning platform and can't remember the last time I looked at the news feed. That doesn't mean that it's unfair to criticize Facebook for the effect it has on those who can't resist doing so. To put it more concisely: while it's true that smart/competent people can think critically about the weaknesses of their tools and work around them, the need to do so is fairly described as a flaw in the tool.
• jimjimjim 8y ago
  I've found jira works fine except for two things: 1) it's been around for a long time and still doesn't seem to be a good match for agile and 2) once people drink the kool-aid it starts getting used for everything. It works great as a todo list of things that need to be done. But lots of places treat it as the single source of truth and stuff it full with every thing from high-level decisions down to acceptance criteria describing the color of a button.
• rs23296008n1 8y ago
  JIRA is a good way to weed out organisations I will probably not enjoy working with. Kind of like if the interviewer says they have a COBOL or java codebase "they'd like me to look at" even though neither is on my resume. Ironically this is not a criticism of JIRA itself. I use it now like I'd use a woman's bad hair on a date or her declaring her borderline personality disorder at dinner. It's a form of red flag detection / future horrible incident avoidance. The problem with agile/scrum and jira is that it is frequently deployed as a form of snake oil with the expectation that it will instantly solve all that ails them. Instead of something that requires actual support, procedures, daily action as well as simple management follow through to succeed.
• alexnewman 8y ago
  jira and arc i would argue are timestamps. they are tools with a lot of power but are less integrated then today’s state of the art
• solatic 8y ago
  Yay, another Jira bashing article that completely misunderstands Jira. Jira actually does a better job of helping bottom-level workers see the big picture than any other tool in its class, because every issue can be linked to any other issue, not just the Epic that the issue belongs to in the hierarchy but issues in completely separate projects belonging to completely separate teams. It's quite easy and supported in Jira to link bug issues to the customer support issues where customers describe, in their own words, what triggered the bug for them. Jira issues also support rich text in the default Description field to write the prose that the author so desperately wants. Jira is just a tool. If your organization is broken, then Jira won't fix your organization. If people in your organization don't buy in, then the tool won't help them. The comments field that helps people see exactly all of the updates regarding any piece of work - whether that is a small piece of work on the bottom or an Epic - is completely worthless if people still email everybody else. The Assignee field is completely worthless if your organization never assigns issues to people, and it's even more worthless if your organization wants multiple people to be responsible for an issue, which is an organizational antipattern. If you host Jira on-prem and don't give it enough resources, or do stupid shit like putting the Lucene indexes on networked storage (if I had a dime for every enterprise infrastructure team which only offered a single class of networked storage...), then you will have a Bad Time. It's a controversial tool because it's Conway's Law made visceral. If your organization is dysfunctional then your Jira instance will be dysfunctional. If your organization Gets Shit Done™ then Jira will help you organise and get even more shit done. I'm not sure it's fair to criticize Atlassian for failing to fix the majority of dysfunctional organizations out there.
  • whorleater 8y ago
    >I'm not sure it's fair to criticize Atlassian for failing to fix the majority of dysfunctional organizations out there. when JIRA is marketed by Atlassian as the tool that will make your dysfunctional organization functional, then yes, it definitely is fair
    • Jedi72 8y ago
      In the land of bullshit advertising which we all live, Atlassian are the least guilty of being immoral.
• techntoke 8y ago
  Issue & project tracking belongs in tools like GitLab or Phabricator, not JIRA.
• ilaksh 8y ago
  I agree with the issues raised by the article but disagree with the conclusion. Prose is great but the way he suggested creating an architectural doc up front doesnt sound like it can evolve as the trench warfare progresses. I feel like a big part of the issue is the disconnect between management and development people in many ways. Most managers only really care about the surface level of the software. Their situation of not being able to directly control the guts and the fact that their boss only sees the surface level reinforces that. Another issue is that management expectations are almost always unrealistic. It's the nature of software development because it is a research process where it's exponentially easier to envision the next step than it is to implement it. My current belief is that both project managers and even executives need to be forced to look at at least some code every now and again and included in software engineering meetings routinely. That is the only way they will start to understand the scope of the work and realize that there is work under the surface.
  • marvin 8y ago
    I think the reasoning must go one step further -- project managers and _especially_ executives need to have rich personal experience with building software. That doesn't necessarily mean that they must have spent years programming for themselves, but at the very least they should have spent a few years closely paying attention to the whole life-cycle of software projects. That way, they can appreciate the difficulties of estimating delivery timelines for an evolving scope, the nasty surprises that will invariably bite them in the ass, what technical debt means, the value of refactoring and consolidating, how something that sounds simple can be hard and the canaries that indicate a certain feature has that property, and so on. The most formidable product person I know has spent six years working closely with a team of five engineers, on a portfolio of complex products. He can often predict technical challenges before the engineers see them. He's the best tech executive we dream of in our organization, but due to the diseased nature of executive hiring at our firm, it's not very likely he'll get a job at the top.
  • grogenaut 8y ago
    I use architecture docs constantly at work as a way to scale myself. I can get a decent first cut 4-8 page doc with problem summary, rationale, implementation (usually api and some schemas), interaction diagram, alternatives considered done in a 4-6 real world hours now. This is for a 1-3 engineer month sized project. I also find I can get a 3 page one done with less details on schema and api in about 1-2 hours. I find that being able to do this allows me to scale myself a ton. I can take a discussion I had with other engineers in a design session, or my thoughts on an implementation, written up quickly. I can then take these docs and send them around and have a concrete place for everyone to start discussion. I find even if my idea is not what others are thinking, it greatly helps them articulate the delta and why. The opposite is everyone sits in a meeting and argues for their point of view in parallel while they do the design on their idea in parallel, which causes more fighting. So to me the cost of an arch doc is not very high anymore, and the effectiveness is very high. I can send that doc to 30+ people and not have to have the same 1-2 hour conversation over and over. However it took me quite a while to be able to get my thoughts onto paper that fast. I also find the 1-3 page writeups help me sell managers on spending the time on the longer doc either for me or their team. The other thing that has been great for me is that I can write up distracting ideas (I have bad shiny object syndrome), quickly, and get them to my peer manager. This means I can go back to my current work without worry about it being forgotten about. Usually I get feedback in a day or so from the manager on how good the idea is and where it fits priority wise. This allows me to innovate and implement at the same time.
• BjoernKW 8y ago
  Jira is an incredibly flexible business process tool that - among other areas - lends itself particularly well to software development processes in larger organisations. With all the criticism levelled against it I have yet to see a better tool of this kind. Jira isn’t opinionated about the process that’s implemented with it. If you want that there are alternatives such as Basecamp for instance. If you want something simple there’s always GitHub Issues (or similar tools). If you need something customised then other than building a tool yourself Jira likely is your best alternative (unless you want to manage your process with Excel sheets, that is ...). If, on the other hand, your process is broken and built around anti-patterns then yes, Jira will absolutely help with fostering and perpetuating those but it’s really not the tool that’s to blame in that case.
  • vassilyk 8y ago
    At last a comment mentioning alternatives. Jira is the primary target of the article when it probably should be how people run agile projects, and how organizations tend to struggle findind the most efficient (software development) processes to reach their business goals. This article could have been written for any similar Jira direct / indirect competitors like you mentioned, and the like of Asana, Trello (Atlassian), Aha, plain old Word, Excel and so many others. But it wasn't, because it's just easier to pick the elephant in the room and have a go at what remains a great tool when used wisely. Kind of like pen and paper, after all.
• brightball 8y ago
  Most of these complaints are with Scrum IMO
• lucas_membrane 8y ago
  Biggest problem when I used it, could not assign anything to more than 1 person.
• iainmerrick 8y ago
  If Jira is a good tool for making software, why isn’t Jira itself better?
  • anonytrary 8y ago
    Because when Jira was made, Jira didn't exist, so Jira didn't have the benefit of using Jira. /s
    • iainmerrick 8y ago
      So refactor it!
• adrianmonk 8y ago
  Jira is a tool for executing the implementation portion of your software. Notice I did not say implementation phase. Also notice there is a design portion of software. It's important to distinguish between design and implementation. Creating a plan is not the same thing as executing the plan. All these things can overlap and have feedback in both directions.
• crankylinuxuser 8y ago
  Usual of tech writing - set up a false premise, answer with bad solution, and then summarily tear it to shreds. I work in an agile environment, and our ticketing system is Jira/Confluence. And I do not see what this person is talking about. 1. Agile tickets include a 'Story', which says "As $person, I'd like to be able to do XYZ." The very ticket entails a basic line of sanity checking to prevent 'do ticket->close ticket->dont care' loop. 2. One rarer things with Agile is 'Desk Check' ( https://www.techopedia.com/definition/18825/desk-check https://www.techopedia.com/definition/18825/desk-check ). This is when a new thing by devs is done, and then they pull the designer AND qa at the dev's desk and do a sanity check on the very card, before it moves on. This solves design misunderstandings and potential QA misunderstandings/bad process before continuing. 3. Spikes are done to determine how big a major thing can be. It's a first round rough draft of 'how big is this feature, really'? The result from a spike can then be made into an epic. The epic is a way a person doing tickets can understand the big picture.
• ryandrake 8y ago
  Whenever one of these discussions starts, it's usually about 50% of the complainers saying "I don't specifically like JIRA" and 50% saying "This isn't about JIRA--I don't like the idea of using any kind of ticketing system to plan, track, and execute projects". The first argument is fine. Personal preference. You might have a different one you like best. I've used close to a dozen issue trackers, and to me JIRA is pretty much middle of the road. Not great, not cancer. It does a job, and is kind of a pain to configure. But to argue against the very idea of tracking bugs and features in a database? That's kind of bonkers unless you're a one-person development team and also double as the product owner, UI designer, and QA tester, and you don't have managers or other stakeholders who want to be able to know how far along the project is. When your team size is >1 and you have more than a single day of work to do on the project, you need some kind of tool to organize and coordinate planning, design, development and testing activities. What are you going to use? Excel? Handwritten notes? I'd love to hear from developers who successfully finished a team development project without a bug tracker. At the risk of staking out a provocative position: I don't think it's even possible.
• arnonejoe 8y ago
  Amen.
• diminoten 8y ago
  Almost everyone in this comment section is getting the article wrong. > JIRA1 is all too often used in a way which makes it, inadvertently, an industry-wide “antipattern," Key phrase here is "all too often". > That antipattern is not JIRA’s fault … exactly. But JIRA’s structure contributes to it. > It’s very good when you’re at the point where breaking things down into small pieces and finishing them sequentially does make sense. And, unsurprisingly given its history, it’s exceedingly good at issue tracking. These quotes seem to be missed by folks here. This article isn't about JIRA, really, it's about JIRAs use across many companies. These comments are so transparently defensive, I'm actually surprised by how poorly understood this article is.
• angry_octet 8y ago
  You can use a good tool to implement a bad software development practice. The focus on closing tickets comes from people who are too focused on the details and covering their patch, and that will happen with or without JIRA.
• flocial 8y ago
  This is a beautifully written article but at the end of the day the way a business uses a tool says more about the organization than the tool itself. Is Jira a tool of oppression or liberation? It can be misused by managers to bully whip a chain gang or just as easily become a developer's best friend when a performance review is coming up (the same way a rock solid alibi will help you survive police questioning). While I agree about how wonderful it could be if used right, it's easily abused and hard to remedy once it becomes a todo list from hell. My guess is the larger your organization and the more rigid your corporate culture is the benefits of tools like Jira will outweigh the cons (not mention the lock in effect once it's adopted).
• DyslexicAtheist 8y ago
  off-topic but using Jira (developed by Australia based Atlassian) sounds like a massive security risk due to "aabill". checking twitter there isn't even a statement by Atlassian or any critic of the bill. looks like Australian tech companies simply don't care https://twitter.com/search?q=%40atlassian%20aabill&src=typd https://twitter.com/search?q=%40atlassian%20aabill&src=typd Btw FastMail too is based in Australia (and in comparison to Atlassian is at least vocal against the bill).
• iblaine 8y ago
  Just because a tool gives you enough rope to hang yourself with, doesn't mean it's a bad tool.
• democracy 8y ago
  Jira used to be hip and all, being written in Java helped with early adoption but these days it is a monster and reminds of me HP QC monstrosity - which is exactly why we moved off HP to Jira long time ago.
• makecheck 8y ago
  The more these things try to be, the worse they seem to fail at the basics. We desperately need more solid basics in our everyday tools. I want JIRA to just load and display the simplest of content, and it often doesn’t. There is no way to predict when Unexpected Server Lag will occur either. If you believe Murphy’s Law, it’ll happen exactly when I finished typing a long-ish important update to a bug that then won’t submit (and like too many web tools, you’re screwed at that point: there’s no sensible way to “stop” it and you’re 90% sure that “Back” will erase everything you just wrote).
• ineedasername 8y ago
  Isn't this a product of the agile method though, and jira simply instantiates it? the whole epic -> story -> subtask methodology seems to be a large part of the article's complaint, but that's really not jira's fault.
• suff 8y ago
  The author either does not know about 'macro' views e.g. burndown charts, or is willfully ignorant. Also, obviously does not realize you can change the custom set of ticket states to match your team's process. It absolutely allows greater than 'one-way lifecycle'. Clearly there is a lack of familiarity with the product.
  • shortlived 8y ago
    They also seem ignorant of the Portfolio plugin which provides a macro view (above epic level).
• evrydayhustling 8y ago
  > What’s more, feature-driven JIRA does not easily support the concept of project-wide infrastructure which does not map to individual features... the spiderweb of dependencies which result don’t help anyone. Disagree. You can make projects about infrastructure, and talk about releasing features of the infrastructure -- e.g. a new parameter in your cache interface. If this grates -- perhaps your description of an infrastructure update includes updating all clients which could utilize the update? -- then you may be facing productive pressure to decouple systems by defining and versioning an interface.
• geophile 8y ago
  TFA says that the problem is Agile run by bad managers. Why the hate for this tool used to implement Agile?
• deleted 8y ago
  [deleted]
• m3kw9 8y ago
  There is always a document outside of JIRA that describes high level, just have to find it. I really don’t think this is a JIRA problem.
• hnruss 8y ago
  It is the responsibility of the product owner to write requirements in such a way that also conveys the big picture. It is the responsibility of the engineer to understand the big picture before implementing requirements. Perhaps Jira could be improved to encourage better communication about the big picture. I’m sure there are plenty of other ways to do that already, though.
• yason 8y ago
  Any discussion about the relative merits of task tracking software is moot because of fundamental discrepancies with regard to tracking tasks. Programmers don't need task tracking. They have an in-head priority queue of stuff that needs to be done, and often doing that stuff will cause insertions into the queue that will completely reshape it. If you make a copy of that queue into a system the result is a pixellated representation of the original data and it's probably outdated by the time you finish making the copy. Programmers might have a TODO.txt or a post-it somewhere to remind them to not forget some unrelated stuff, but generally once a programmer knows what needs to be done and why the work will partition itself, in the right order, and into right sized chunks. The queue is rather alive and zooms in and out all the time. Managers don't need task tracking either but they think they do. What they need is a way to measure progress and completion. A manager's task queue is a very different queue from what the programmers have in their head. Most of the time, you can't map items from the programmer's queue into the manager's queue. The reason is that in the programmer's queue all items take the time it takes to complete items and thus items come in different sizes. In the manager's queue the items have time estimations and progress percentages and they're split into manageable chunks of time; if not hours at least usually days. So, managers get this idea that they can ask programmers to maintain a copy of their internal queue and save time and effort by reporting progress from there. Usually this takes the form of a task tracking system. The pixellated result that managers get from the programmer's queue is data which managers then need to reinterpret as information when reporting up. All they need to report back to other managers and higher ups is the progress, how well the work is within the estimates and when will it be complete, and a few answers to "whys" of what's causing delays or why something new needed to be done. But the programmer's queue has none of this information so dilbertesque creativity is unavoidable during converting programmer items to manager items, dragging everything farther from the truth especially if the managerial copy is ever fed back to engineers. The programmer will think the result is ridiculous and doesn't at all match what's in his own queue. The manager can't see what's exactly wrong with it except that programmers are bad making estimations and the tasks are badly scoped and larger than they were planned, thus completion is prolonged each week. A signs of this happening is that tasks being tracked don't match with the tasks being worked on. There's some overlap but some tasks are suspiciously simple while others are too vague, and there's unreported invisible work that sometimes takes the majority of the wallclock hours of a week. The programmer could only ever supply correct information when everything is done and tested while at that point the manager doesn't need it anymore as he can report back "100% complete". If the programmer is asked to provide more fine grained subtasks he will either spend more time pleasing the manager rather than doing real work or he will first work with no plan and no tasks for quite some time until he has enough information to add the appropriate subtasks into the system. Fine-grained tracking also eats into the free flow of the in-head queue of the programmer: if rearranging the work queue (which happens all the time) gets expensive it creates a barrier to let the work flow towards completion. The programmer either gets stuck with the existing tasks or disregards the tracked tasks completely and continues alone where the path of code takes him. Regardless, the data in the manager's queue will certainly end up being inaccurate, incomplete and outdated. Programmer also has to do extra work simply to work around and between the manager's queue and his own queue. No system can fix this. Good communication is the key, and if you have that you don't want a system to make it slower. Task trackers are useful for individuals to keep things ordered to satisfy their own scheduling needs, but they don't solve the inherent gap between managerial schedules and programmer schedules.
• aidenn0 8y ago
  > Isn’t agile development supposed to be fundamentally different from waterfall development, rather than simply replacing one big waterfall with a thousand little ones? A thousand little waterfalls is fundamentally different from one big waterfall. One major issue with waterfall is that one mistake anywhere in the process can derail the entire project, and those mistakes are not always apparent until very far in. If your waterfalls all complete in say, under 2 months, then you don't lose any more than 2 months with any single item that is a total failure (partial failures can be even less disruptive). I'm not the biggest fan of the word "agile" but this idea seems like a very important point of many things that call themselves agile, and it damages the ethos of the author's argument to have such a basic misunderstanding.
• afpx 8y ago
  The comments here are funny. Iterative-incremental software processes have been around for 40 years or more. I’ve been developing software for 25 years, and I’ve never seem anyone use “waterfall”. As far as I know, it hasn’t been widely used since the 50s. Scrum was a way to “dumb down” software processes for neophytes. But, it doesn’t guarantee success. No specific process can guarantee success; it always comes down to the quality of the engineering staff. And, if your engineering staff is skilled and experienced, they won’t need a defined process anyway. JIRA is just a system to track deadlines and deliverables. “Processess” are things contrived by consultants to be able to sell tickets to expensive conferences.
• warpsprung 8y ago
  As a bug tracker YouTrack seems to be much more usable and more powerful than JIRA. If you want a bigger system for everything including Requirements Engineering give codeBeamer from Intland.com a try. Everything is freely configurable. Much better than the typical ALM systems.
• trixie_ 8y ago
  If I had a nickel for every time a PM was proud of themselves for creating a zillion tickets...
  • yyx 8y ago
    If I had a nickel for every time a PM didn't create a ticket…
    • trixie_ 8y ago
      If I had a nickel for every time a developer was unable to create their own ticket.
• crazy_monkey 8y ago
  I sometimes use JIRA to emulate a Turing machine. It's never halted on me yet!
• znpy 8y ago
  I understood that the article was flawed from the point where the author called software engineers "crafters". That being said, we use Jira at work and it has been serving us well. Really, I can't complain.
• jedberg 8y ago
  What this article seems to be missing, as does most of the comments here, is the distinction between software engineers and architects. Everyone likes to rip on the “architects that do no real work”, but this is exactly the problem and architect solves. Their job is to understand the macro picture, the user’s use cases and the business use cases, and be technical enough to then digest that all into tickets of small chunks of work such that the software engineer can implement the right thing. It is the architect that holds the context and hopefully passes the right amount of that context through the ticket. In the author’s metaphor, it would be the architect who would design the electric and water grid and decide which houses go where and who will build them and how. And then monitor the whole project and change things as issues come up.
• Ericson2314 8y ago
  The number 1 feature in all these tools should be dependencies. And yet it's always a stupid afterthought with no love.
• linuxhansl 8y ago
  It's just a tool... We use it a lot for Apache Open Source projects. It's good enough to keep tracks of what's a release, etc. Of course you do not use for mini-specs, etc.
• matchagaucho 8y ago
  "JIRA encourages the disintegration of the macro vision." That's a questionable use of the tool. Decomposition is the agile approach, with modular deliverables that can be parlayed into future stories.
• mbrodersen 8y ago
  JIRA works great for me and the company I work for. Don't blame the tool if you don't know how to use it.
• sheeshkebab 8y ago
  To paraphrase Winston Churchill, JIRA is the worst tracking tool, except for all the others. https://winstonchurchill.org/resources/quotes/the-worst-form-of-government/ https://winstonchurchill.org/resources/quotes/the-worst-form...
• passive 8y ago
  I've worked with JIRA (and Confluence) on a daily basis for the last 6 years. During that time, I have personally spent months of time working on JIRA, to make it do what we wanted. Before that, I worked with JIRA on-and-off for 7 years (with Trac and Rally tagging in here and there). Which is all to say, I know me some JIRA. The fundamental thing that this article points out is that JIRA tickets are about work, not software, and as a consequence of wanting to track our software, most users of JIRA spend a considerable amount of time and money approximating the tracking of software. (No, Confluence isn't for tracking software either. It's for filling in the more flexible pieces of data that JIRA doesn't handle so well.) This is correct, but I would say calling it an antipattern is going too far. A well-customized JIRA is probably the best system in existence for approximating the tracking of software. But (probably) it doesn't have to be, which is hopefully where the author was trying to get. Something like Github issues, for example, binds code to "tickets", which at least conceptually is a step in the right direction. But software is quite a bit more than code, which is why our JIRA has tickets related to provisioning infrastructure, deploying, managing data, etc. I'm not aware of any JIRA alternative that considers all these facets of software creation holistically, though it's been a year or two since I looked into it seriously. there are a lot of ways to develop software, and maybe designing a useful system that encompasses all potential aspects becomes too abstract to actually be efficient. What I can conceive of is something of a mash up between JIRA and BDD, where desired changes are first described as a new end-state, and then the necessary work to achieve (and automatically validate) that state is broken off in tickets that are linked to that end-state description in some way. The key being that that first description is always your source of truth about the software, with the linked tickets helping organize the work before it is ready, and serving as reference information afterwards. We are close to approximating something like this with Gitlab, JIRA, and Radish-BDD, but it's a lot of wiring and educating about conventions. I think you could do it in a single piece of software.
• rhacker 8y ago
  We use Jira but it has such a vast disconnect from how the mind works. I'd rather have a shared document that has one liners like so: New reconciliation engine [x] Migrate to new prod db [ ] Add feature to copy study objects (jim can explain) [ ] Move study list rest service to graphql ... Inverted micro editor [ ] ...
  • eat_veggies 8y ago
    You can do this with trello right?
  • hliyan 8y ago
    Interestingly, if you copy & paste the above text into a Github issue description, you'll see that it works exactly as expected. My problem with Github issues: need "Affected Release", "Fix Release" fields.
• jugg1es 8y ago
  Doesn't this have more to do with how people are using the tool rather than how JIRA markets it? If you expect one piece of software to solve all your problems, then you don't know a lot about how software gets designed.
• drb91 8y ago
  This seems to be railing against the concept of beureaucracy, which JIRA naturally reflects. Is this really tool-oriented at all? All criticisms here could be levied against Trello, Asana, or post-it notes on a wall.
  • pspeter3 8y ago
    Can you elaborate?
• yashksagar 8y ago
  I don't think the analogy of town planning fits well. I think it depends how the tasks are broken down by the team. What if the tasks are created in the breadth-first approach, so that the goal is not to "fully complete" each neighborhood, but to get each neighborhood in a working state, like the "organic" approach the author mentioned? I have found success using this approach on my team. And yes, agreed that we should use other software like Docs or Sheets for the project homebase, and only limit JIRA to Epics/stories tied to labels for the projects.
• sixdimensional 8y ago
  I know that there was a backlash against it, but sometimes I find the simplicity of the Agile Manifesto to still be a good reminder not to get carried away with a highly specific way of doing things. There needs to be a balance. "Individuals and interactions over processes and tools... ...That is, while there is value in the items on the right, we value the items on the left more." [1] In this case, highlighting all the discussion about JIRA vs. what you actually do / what works for you / your team / product / organization. [1] https://agilemanifesto.org/ https://agilemanifesto.org/
  • pjbk 8y ago
    "We are so Agile that we are not agile anymore"...
  • EdCoffey 8y ago
    Yep. Jira isn't an antipattern; inverting the first value of the agile manifesto is an antipattern, whether you do it for Jira or any other tool (or process).
• jib 8y ago
  Feature decomposition is an antipattern. This is not related to JIRA. Features are the result of integration of systems. Starting with features is insane. Design the system, then integrate parts of the system to create features. I don’t think prose is the answer, but it certainly sounds better than starting with features. If you get the chance I’d recommend taking the architect/project design master classes by Jowal Lowy. If you can stand the delivery the message is extremely on point.
• moron4hire 8y ago
  JIRA is a pretty flexible tool. We use it primarily because it is a ticket list that we've been able to get approved in our corporate IT system. Personally, I prefer Trello, but no tool is going to be a substitute for good management. If your projects are failing, it's because of lack of communication in the team, which will happen with even the best tools, and can be done well without even the worst tools.
• snambi 8y ago
  Jira is an ugly ticketing software. Hope developers get rid of it ASAP.
• temporallobe 8y ago
  JIRA is not a drop-in replacement for good ol’ fashioned software design and documentation, and no one ever said it was. The author mentions things like common models and complex cross-application components. Who ever said JIRA was supposed to somehow capture those things? It’s not! If you’re using JIRA for things like that, you’re doing it wrong. I think the danger is that JIRA IS being used more and more as a design and documentation tool while we ngleglect using some of the more well-established practices of years past, such as use-case diagrams, class diagrams, requirements documents, wireframes, etc. We try to capture too much design in the various types of tickets, but that in my opinion is wrong because JIRA was not originally designed for that. In that way, JIRA itself is not a anti-pattern, but how we use it certainly can be.
• Myrmornis 8y ago
  I admire the author of this piece for being able to concentrate on the bigger picture of how JIRA is bad in important ways, despite the millions of ways that JIRA is bad in minor ways that make anyone who uses it absolutely hate it for trivial reasons without even getting to think about the bigger picture. If you were going to decide not to support markdown, wouldn't that decision make more sense if you had front end engineers who were even vaguely capable of implementing a custom mark-up language?
• paulie_a 8y ago
  Jira tickets are generally devoid of specific information. What am I actually expected to do. List it out. User stories are an incredibly useless concept in the current implementation. And the new interface on jira is a piece of shit. I will say it again, jira sucks when it comes to UI. Just because a ticket exists doesn't mean it has useful info or potentially matters anymore.
• DevKoala 8y ago
  I feel you get as much of the tool as you are willing to put into it. I personally abhor the tool and prefer working with engineers who can own full services and applications from end to end. That way the discussions are held at the architectural interface level with the goal in sight always. I have only found JIRA is useful for tracking the implementation tangential TODO items such as monitoring and alerting, extra data validations, UI style items, etc; tasks that other engineers can implement without the need to understand the full scope and architecture of the project.
• rawoke083600 8y ago
  oh yes ! Jira... everything is possible but nothing is easy... my next software/project-management package i buy,i want to buy a methodology... i.e "we acme inc have figured out how to best track/manage software projects"... NOT here is a tool you can customise to fit every possible scenario and methodoloy...
• gamesbrainiac 8y ago
  Most people reading this article will miss the point. Many will conflate what the right way of doing things is. However, the main point is that JIRA makes the things that you should do, harder while at the same time, making the things you shouldn't do easier.
• mylons 8y ago
  FUCK. YES.
• starky 8y ago
  As someone that uses JIRA for hardware development and hates it, this article really speaks to why it is such a pain point. There is often a lot of moving parts going on in a project, and there isn't much to put down until a task is done, at which point it feels pointless to say anything more than "Temperatures were all found to be within specification. Test report attached." Where something with a much higher level view of the project (maybe deliverables based) would be more useful. When we do have an issue that could be useful to track the status with comments over time, it is such an emergency that nobody documents it until after it is resolved, and you would be lucky to find it in the future with the terrible search anyway.
• vePhi4le 8y ago
  http://tom.preston-werner.com/2010/08/23/readme-driven-development.html http://tom.preston-werner.com/2010/08/23/readme-driven-devel...
• nurettin 8y ago
  jira is an antipattern because tickets could have been opened after careful deliberation? Sounds like management's issue, not jira's.
• omarish 8y ago
  Techcrunch is an antipattern.
• Annatar 8y ago
  "Tickets, in the JIRA mindset, are taken on, focused on until complete, and then passed on, never to be seen again. They have a one-way lifecycle: specification; design; development; testing; release. Doesn’t that sound a little … um … waterfall-y?" It does, because when cold, hard reality hits, the waterfall workflow is the one and only way to system engineer high quality software; there is nothing else and there never was any other technique to achieve that. Agile is a gimmick to give non-engineers free reign, carte blache to keep on hacking like mad until something somewhere finally starts half-working; that's the hard reality of the IT industry.
• afro88 8y ago
  The way he described the organically grown city is certainly a way to do things in Jira. Just write your tickets that way. Don't have a ticket for a whole block, or a whole airport. Have a ticket for the dirt airstrip. Don't write all your tickets in the beginning, write them as things progress. Going back to the start of the article: have a ticket for the caching of the 3rd party service, have a ticket for your data model (your engineering team might be the person the story is centered on in these cases).
• jkdll 8y ago
  The problem in this article can be easily solved by carrying out 'Story Mapping' - the problems mentioned come from not carrying out story mapping in a visible way. The best Product Owners I know have been carrying this process out manually for a long time, but there are also plugins for this: https://www.featuremap.co/en/integration-jira https://www.featuremap.co/en/integration-jira (I am not affiliated with this product). This is a case of a bad workman blaming his tools.
• donjoe 8y ago
  Building a city/neighborhood is a really bad example for an agile development tool: agile development is to be used in case requirements are not yet fully available. In other words, the team is searching for the right and best solution to solve a problem. In the author's example, the city is already fully planned and ready to be build, thus the solution to solve an existing problem already exists. Why to use agile? Building a city/neighborhood is a perfect example for a waterfall implementation strategy which can be perfectly modeled with other tools. As always - use the right tool for the right job and you'll be alright ;)
• cvs268 8y ago
  > But if measured by how many blocks and neighborhoods are absolutely finished, > according to the urban planners’ artistic renditions,what is your progress? > By that measure, your progress is zero. Exactly! Do NOT create individual JIRA Task the size of each building/block. When planning a city, a JIRA Task is something like - "Add switches to the bedroom of apartment 104 in the residential building at lot #10 on Sunshine street." No wonder the author of this Techcrunch article is frustrated with JIRA. He is using JIRA wrong (or more likely is being forced to use JIRA incorrectly) One of the cardinal sins of project planning is to NOT decompose the activities into individual deterministic steps. I have summarised my thoughts in this slide-deck that i find useful in my crusade against unplanned/misplanned projects https://thecodeartist.blogspot.com/2017/04/effort-estimation.html https://thecodeartist.blogspot.com/2017/04/effort-estimation...
• dajonker 8y ago
  I often see a bad split between the ideas/specifications, and execution of a software project. On one side there's the project style where everything is designed and specified by non-programmers (i.e. people who don't end up coding the thing), then thrown to the programmers to make it work. On the other hand there's plenty of programmers that just want to write beautiful code and care little about how useful the result is. In my opinion you get better results when most people involved are fundamentally problem solvers, some happen to be awesome at writing code, and all are working together closely.
• black_13 8y ago
  Its used a replacement for planning and management.
• jsilence 8y ago
  You can't blame the hammer for not holding the nail.
• jondubois 8y ago
  Jira is one of those tools which tend to give managers an illusion of progress at the expense of actual progress. It's not just Jira, there are many tools today which are like that; they aim to give non-technical managers a feeling of control over a technical process which they are often not capable of understanding. These tools are designed to allow non-technical project managers to not trust their technical people - This is a recipe for poor quality results. The best CEO and CTO that I've ever worked for used Trello as their only project management platform and they personally kept tabs on all the main tasks; even as the company grew. They had a good intuitive understanding of how long things should take. There is a really big difference between seeing what needs to be done versus understanding what needs to be done; no amount of advanced project management tooling can make a manager actually understand what is happening.
• luord 8y ago
  Disagree on the implication that the kanban flow (which is essentially what he described by moving stories between different phases) is inherently a waterfall; it is in as much as the idea that a project is expected to be completed (or at least reach feature completeness) at some point is a waterfall. Scrum [1] often does become a collection of short waterfalls, but nothing in the kanban flow prevents a story moving in any direction. He says that epics are not enough to depict the bird's eye view on the project... But he doesn't elaborate how and I certainly disagree. And the city construction analogy is a flawed one. Cities are, in 99.9% of cases, hackjobs cobbled together over hundreds of thousands of years. There are very few cities that were planned from scratch. The "extension to the metaphor" he mentions is essentially every software project --organized process or not-- and it's the archetypal example of the software crisis. Maybe programs are not cities... I also have a very different concept of "huge requirements document" because what he described as alternative is very much a huge requirements document. The comparison to art (even if there's always an inherent artistry in software development) is because he talks about art using "shoulds". No, there are no rules for art, while there should be rules for software development (even if they ought to be flexible). [1] Actually, most of the complaints I agree with (points, too many meetings, loss of the macro view, pressure to deliver whatever at every point and in a set of defined stages) are mostly about scrum, which can be run without jira or any other tools.
• bmjunk 8y ago
  How about we replace all the "Agile and Scrum" bullsh*t jargon and principles with a simple framework called "Common Sense". Do what makes sense for your user and your business. Everything else falls into place automatically.
• optimuspaul 8y ago
  JIRA isn't an antipattern, but it does enable people/teams to use antipatterns. This is silly.
• notus 8y ago
  I don't understand why HN doesn't like or appreciate half assed comments, but then posts like this are okay. All the poster demonstrated was that they don't understand JIRA very well.
• Izkata 8y ago
  This line: > (If you prefer a smaller-scale model, just transpose: city → condo building, neighborhood → floor, block → unit, etc.) is where I realized why this whole post felt wrong. This is how cities are built, a handful of buildings at a time, Jira-style.
  • deleted 8y ago
    [deleted]
• tmaly 8y ago
  I use JIRA in conjunction with Confluence in my teams software process. Confluence holds the requirements and specifications. The project starts there and work on the specification is partitioned into JIRA tasks. So I do not have this issue with macro and micro views of a project.
• blufor 8y ago
  My team (well, mostly just me) are pioneering Phabricator as a replacement for the Atlassian suite. Phabricator has been born in Facebook (it looks a little like FB in 00's :)). Main advantages: - It's rather a framework with dozens of small apps that adhere to the KISS principle - Core elements are Users, Projects, Tasks, Repos (git, svn or hg) and Differentials (like PRs) - Has shitload more, like Pastebin for example - Task can be in multiple projects/views - Tasks can have parent/child relationships - Task can mention other tasks and objects - Has an app called Herald, which handles event-based hooks - Has a CLI tool called Arcanist which replaces git (well, it's rather a wrapper that adds few api calls) - Allows you customize the system to YOUR workflow, not the other way around Disadvantages: - PHP (even for the CLI tool) - MySQL One of the benefits no other tool gave me is that I can backtrack from a line of code to the original Task or its parent epic.
  • blufor 8y ago
    Missed the links https://www.phacility.com/phabricator/ https://www.phacility.com/phabricator/ https://github.com/phacility/phabricator https://github.com/phacility/phabricator
• HeavyStorm 8y ago
  I wonder why this received so much attention. I'm not a JIRA advocate, but the author seems to have missed a lot of what JIRA is about and is just venting about some badly managed project he experienced, and, as most of of us do, is blaming the tool for the human mistakes. There's somewhere a conversation worth having, like how everything is an issue on JIRA (which most open source projects follow anyway) and indeed how agile methodology seems to to push us to forget about the big picture sometimes, but certainly blaming the tool for granularity issues of the stories is completely unfounded. Besides, it works - I've delivery many projects using the tool effectively, even if sometimes I wish all I had was a kanbam.