JIRA is an antipattern - <AUTHOR> https://techcrunch.com/2018/12/09/jira-is-an-antipattern/ <comment><USER2> > 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.

<comment><USER3> I think you've hit on the fundamental contradiction of agile and scrum.

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

The implementation of this functionality in a way that will delight customers could hypothetically take 3 weeks as it requires the implementation of an upload button, a datastore to store the uploaded values, and an integration into a legacy feeds system to get the spreadsheet's data to all of the places it needs to go.

In most scrum processes 3 weeks of effort would not be accepted, and the story would be "broken down" into smaller issues such as "implement an upload button". Even worse scrum projects emphasize anti-patterns of "parallelizing" efforts, so we'll assign each of those smaller stories to separate individuals. While theoretically a customer focused engineer could look at the original user story, there is minimal incentive to do this - and most engineers will focus on pushing stories across the board, the upload button may or may not ever work in a way that customer's desired - and any attempt to fix it requires restarting the whole process.

<comment><USER2> > In most scrum processes 3 weeks of effort would not be accepted, and the > story would be "broken down" into smaller issues such as "implement an > upload button".

Yes, but a good scrum process goes like this:

1) the PO presents the story

2) the developers discuss it, and find that it doesn't fit into a single sprint

3) developers and PO together break it down into small issues, for example by turn the original story into an epic, and creating more, smaller issues in that epic.

So when a developer works on the smaller story, they have heard about the context before, and have a link to the epic with the broader context in case they have forgotten.

It's not automatically provided by Jira, but if you use the tools correctly, you can absolutely provide that context.

<comment><USER4> Bah this process is faulty, we use it at work and this means that a feature which has to manage N things is almost always split into 'manage 1 thing' then 'goes from 1 to N' even though it takes more work and the resulting code is much more ugly..

<comment><USER5> If your problem's complexity is big enough, you can't get good solutions without an explicit architecture step. I've seen quite a few bad ad-hoc architectures being created trying to break down epics that were too big. Your team needs a lot of discipline to come up with a good plan/architecture (per story/epic at least) first. Scrum did not help here, to me it seems it legalized hacking away the day... In some domains you can't pay back that kind of dept easily...

The article may have a clickbait headline, but "have an overview and use JIRA in addition to track the leafs of the work hierarchy" is true.

What I found is that almost all projects try to organize as tree but they should organize as matrix, at least if there are many cross-cutting components.

<comment><USER6> If my team had that much discipline to begin with, they'd do just fine without Scrum.

</comment></comment></comment></comment></comment></comment><comment><USER7> 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.

<comment><USER8> Asking seriously: is it that it's not possible with today's tools, or philosophically not possible?

<comment><USER9> 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.

<comment><USER10> 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.

<comment><USER11> Is the idea behind this "I can only focus on one thing at once, so unassigning myself allows someone else to take up the task in the intirim", or something else?

<comment><USER10> Mostly this. Obviously, this assumes shared understanding of assignments as "things I'm working on" rather than "queue of things and also commitment do to everything".

Combining the original "one open ticket" rule with the second approach is rather bad. That's why I hope it was used in the context of the first approach.

</comment></comment></comment></comment></comment></comment><comment><USER12> _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?)

<comment><USER13> > 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.

<comment><USER14> > _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_.

</comment></comment></comment><comment><USER15> 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.

<comment><USER16> 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.

<comment><USER17> It's very interesting to read this. I've come around to the exact same ideas, with the same perspective, and for the same reasons you've listed here. I've also had the same experience. These docs are critical for my team at this point. Without them, we'd go back to languishing for any number of weeks while we grapple to understand the larger context. All of that said, it takes me at least 2x longer to get these documents created. It's easily a 1-2 day affair for me. I'm also on a small team, with only 4 engineers, and the projects we work on tend to run 1-3 months. I wonder if this process scales to larger teams and projects.

<comment><USER16> It used to take me that long. For more detailed docs it still does. I'm also way slower when it comes to business justification and executive team arguments but getting better. Practice makes perfect though. 5 years ago it would take me multiple months to write such a doc and I'd get bored constantly. Now I'm much faster. Some of my mentors can do these things on the fly in a meeting and drive consensus easily on stuff they have 0 context on.

I also got better because I had a manager who suggested that I just start writing these things up for a few hours each week. Just like authors who say that you have to write to get better at it, and how you write essays in high school and college even for arguments you don't believe in.

As for scale the process, yes it seems to. We try to review anything that's 3 months engineer time or more with a Sr. engineer from another team. Wider for larger projects. Bring in Principals when you have real quandaries.

The trade off is really writing time to communication effectiveness. If you find yourself having the same slack discussion more than 2x, maybe it should be in a document.

</comment></comment></comment></comment><comment><USER18> 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).

<comment><USER19> > Having small-scale tickets that you actually finish is the very essence of > agile

Bollocks.

The "highest priority is to satisfy the customer through early and continuous delivery of valuable software."

Not tickets, small or otherwise. Not _tasks_. It has nothing to do with two- weeks.

> Ignoring the "wider vision" is the best way to produce software that > actually solves people's problems

I have no idea what you could possibly mean by this.

Every time I've ever seen a _modular_ development that isolates developers from the business (or from each other), I've seen brittle software, and that's assuming they get done at all.

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

Listen, if software helps you, then great, but if your whole life is "pushing tickets", you're not doing Agile. It doesn't matter if you're using Jira or Jello.

[https://agilemanifesto.org/principles.html](https://agilemanifesto.org/principles.html)

<comment><USER20> The problem with Agile is that no one is doing True Agile™, because no one can agree on what True Agile™ is.

<comment><USER21> Do not try to do True Agile, only try to realize the truth. There is no True Agile.

To me, Agile is really a set of principles to help you decide what to focus on (e.g people over processes). The different methodologies (scrum, kanban, etc) are just frameworks to help you build the best dev process for your team while trying to keep the agile principles front and center.

In reality, all kinds of factors get in the way of True Agile - experience of devs, team dynamics, company incentive structure, management expectations, management's management expectations, how the company handles failure and the subsequent ownership vs finger pointing, etc. The actual implementation of Agile should be different for each organization because the environment in which they operate in is different. With that said, there are certain core principles and practices that are very beneficial across the board and consistency across teams within an organization certainly helps.

</comment></comment></comment></comment><comment><USER22> 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.

<comment><USER23> >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

<comment><USER24> In the land of bullshit advertising which we all live, Atlassian are the least guilty of being immoral.

<comment><USER25> We can blame multiple companies for bad advertising at the same time. There is no priority queue there.

</comment></comment></comment></comment><comment><USER26> 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.

<comment><USER27> 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.

<comment><USER28> That emphasis on features over bugs is a myth. Look at almost any Apple developer's assigned Radars and they're mostly bugs. Pay attention to Craig Federighi's initiatives and stability, security and bug fixes have taken a top-priority at least over the past year or so. Look at iOS 12 and Mojave for public examples of this focus. People complained that iOS 12 didn't have a lot of new features, but it's almost universally acclaimed as far more stable and performant than iOS 11. Same for Mojave. Compare that to the release of Sierra for example.

<comment><USER29> That could just come down to Apple's cycle. They tend to do one release with a lot of features, then one release for stability. The precedent was set with Leopard and then Snow Leopard, repeated with Lion and Mountain Lion, and so on.

</comment></comment></comment></comment><comment><USER30> 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.

<comment><USER31> 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.

</comment></comment><comment><USER32> 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.

</comment><comment><USER33> 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.

</comment><comment><USER34> 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.

<comment><USER35> 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.

</comment></comment><comment><USER36> 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/)

<comment><USER37> 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).

</comment></comment><comment><USER38> 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.

<comment><USER39> 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.

</comment></comment><comment><USER40> 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.

<comment><USER41> 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.

<comment><USER40> > What if that turns out to be an inefficient (poorly-architected) way to > break it down?

Don't break out later stages too early then! Just enough to get to MVP. That is the essence of agile and XP isn't it?

<comment><USER41> If I don't break them out "too early" then that often means I'm not breaking them out until I'm almost finished :)

<comment><USER40> > but it can take implementing virtually the entire thing to get your head > straight.

Seems to fit your needs then!

<comment><USER42> Well, the developer didn't need it in the first place. It is not a useful tool for developers as we have better tools for developers. It is management that wants to see the work up in pretty JIRA lights and they want to see it before the project is already done.

</comment></comment></comment></comment></comment></comment><comment><USER43> 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.

<comment><USER44> 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.

<comment><USER45> 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.

<comment><USER44> 1.5–2.5 seconds is slow. (Faster than I'm getting, though, I'll give you that.)

</comment></comment></comment></comment><comment><USER46> 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.

</comment><comment><USER47> 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.

</comment><comment><USER48> > 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.

</comment><comment><USER49> 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).

</comment><comment><USER50> 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.

</comment><comment><USER51> 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.

</comment><comment><USER52> 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.

</comment><comment><USER53> 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).

</comment><comment><USER54> 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.

</comment><comment><USER55> 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.

</comment><comment><USER56> _> 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.

<comment><USER19> > 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.

<comment><USER56> _> 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".)

<comment><USER19> I think you misunderstood me/I was unclear.

Yes, the macro-level view belongs in prose. In a word-doc perhaps.

All I meant was that this doesn't preclude the use of tools like Excel (or Jira) to break up tasks into items and estimate their cost. If you like doing that, then great: you're not doing anything wrong.

</comment></comment></comment></comment><comment><USER57> 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.

</comment><comment><USER58> 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
            [ ] ...

<comment><USER59> 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.

</comment></comment><comment><USER60>
      > 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...](https://thecodeartist.blogspot.com/2017/04/effort- estimation.html)

</comment><comment><USER61> 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.

</comment><comment><USER62> 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.

</comment><comment><USER63> 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.

<comment><USER63> Missed the links

[https://www.phacility.com/phabricator/](https://www.phacility.com/phabricator/)

[https://github.com/phacility/phabricator](https://github.com/phacility/phabricator)

</comment></comment><comment><USER64> 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.

</comment><comment><USER65> I've yet to see a bug system that is anything close to as good ss Bugzilla was in 1998.

<comment><USER66> What was good with Bugzilla that you miss from the likes of Jira?

<comment><USER67> 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.

<comment><USER66> 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?

<comment><USER67> 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!

</comment></comment></comment></comment></comment><comment><USER68> "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.

</comment><comment><USER69> 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.

</comment><comment><USER70> 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.

</comment><comment><USER71> 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).

</comment><comment><USER72> > 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.

</comment><comment><USER73> 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 ;)

</comment><comment><USER74> 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.

</comment><comment><USER75> 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?

</comment><comment><USER76> 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.

</comment><comment><USER77> 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.

</comment><comment><USER78> 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).

</comment><comment><USER79> 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.

</comment><comment><USER80> 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?

</comment><comment><USER81> 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.

</comment><comment><USER82> 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.

</comment><comment><USER83> 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.

</comment><comment><USER84> 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.

</comment><comment><USER85> 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.

</comment><comment><USER86> 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.

</comment><comment><USER87> 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.

</comment><comment><USER88> 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.

</comment><comment><USER89> I find Azure Devops (VSTS) to be just as poorly designed for this purpose of macro design. Work isn't a linear process.

<comment><USER90> 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_.

</comment></comment><comment><USER91> 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.

</comment><comment><USER92> To paraphrase Winston Churchill, JIRA is the worst tracking tool, except for all the others.

[https://winstonchurchill.org/resources/quotes/the-worst- form...](https://winstonchurchill.org/resources/quotes/the-worst-form-of- government/)

</comment><comment><USER93> 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.

</comment><comment><USER94> 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.

</comment><comment><USER95> 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.

</comment><comment><USER96> 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.

<comment><USER97> How about a Gantt chart? It's a time based resource planner.

</comment></comment><comment><USER98> 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.

</comment><comment><USER99> 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.

</comment><comment><USER100> [http://tom.preston-werner.com/2010/08/23/readme-driven- devel...](http://tom.preston-werner.com/2010/08/23/readme-driven- development.html)

</comment><comment><USER101> Issue & project tracking belongs in tools like GitLab or Phabricator, not JIRA.

</comment><comment><USER102> 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.

<comment><USER103> Can you elaborate?

</comment></comment><comment><USER104> Biggest problem when I used it, could not assign anything to more than 1 person.

</comment><comment><USER105> _" 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.

</comment><comment><USER106> 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.

</comment><comment><USER107> 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.

</comment><comment><USER44> If Jira is a good tool for making software, why isn't Jira itself better?

<comment><USER108> Because when Jira was made, Jira didn't exist, so Jira didn't have the benefit of using Jira. /s

<comment><USER44> So refactor it!

</comment></comment></comment><comment><USER109> 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.

</comment><comment><USER110> 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.

</comment><comment><USER111> 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.

</comment><comment><USER112> The number 1 feature in all these tools should be dependencies. And yet it's always a stupid afterthought with no love.

</comment><comment><USER113> 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...

</comment><comment><USER114> 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.

</comment><comment><USER115> TFA says that the problem is Agile run by bad managers. Why the hate for this tool used to implement Agile?

</comment><comment><USER116> JIRA isn't an antipattern, but it does enable people/teams to use antipatterns. This is silly.

</comment><comment><USER117> Just because a tool gives you enough rope to hang yourself with, doesn't mean it's a bad tool.

</comment><comment><USER118> Isn't that the fact most products get bloated over time, especially when funded in wrong ways?

</comment><comment><USER119> If I had a nickel for every time a PM was proud of themselves for creating a zillion tickets...

<comment><USER120> If I had a nickel for every time a PM didn't create a ticket…

<comment><USER119> If I had a nickel for every time a developer was unable to create their own ticket.

</comment></comment></comment><comment><USER121> 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.

</comment><comment><USER122> Jira is an ugly ticketing software. Hope developers get rid of it ASAP.

</comment><comment><USER123> You can't blame the hammer for not holding the nail.

</comment><comment><USER124> 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.

</comment><comment><USER125> jira is an antipattern because tickets could have been opened after careful deliberation? Sounds like management's issue, not jira's.

</comment><comment><USER126> Its used a replacement for planning and management.

</comment><comment><USER127> 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

</comment><comment><USER128> Most of these complaints are with Scrum IMO

</comment><comment><USER129> Techcrunch is an antipattern.

</comment><comment><USER130> Amen.

</comment><comment><USER131> 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.

</comment><comment><USER132> 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.

<comment><USER133> They also seem ignorant of the Portfolio plugin which provides a macro view (above epic level).

</comment></comment><comment><USER134> 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.</comment>


Ask YC: CMS? opinions? - <AUTHOR>

we are developing web software, although we decided that our company might want to make more than one thing so our first product is going to be seen as that and not the company itself.
We aren't interested in building a company site from scratch since there are good cms' available.
what do people recommend? or would it really be better to build one from scratch since we are supposed to be a web software company.
EDIT: I've been thinking about using Joomla but really haven't decided.
EDIT: on another thought does anyone know of any that are postgres friendly? that's the db we are using for our first product. <comment><USER2> CMS means way too many things these days, and most of them (both the things it means and the software that calls itself CMS) are a bad idea. I say this as someone who has deployed not one, not two, not three, not four, but _five_ large scale CMS systems (Zope, Plone, custom thing based on MoinMoin and trac, OpenACS, and finally Joomla). Deployments used by thousands of users for a wide variety of activities.

CMS systems are usually too big to be right for any particular purpose, and so the majority of your development time is spent ripping out the stuff that gets in the way of your users doing what they want to do at your site...Joomla is actually the worst in this regard, though it shines in a few areas (large number of available applications...though I was disappointed to find that 90% of them are absolute garbage and not worth the time it takes to install them, much less the time it would take to make them look right on your site).

Right now, I'm still maintaining the Joomla site, and not terribly happy with it. Since I have to migrate from 1.0.x to 1.5.x, and this is not a trivial project, I'm considering moving to something else. The lazy in me likes the looks of Drupal--all the apps we need (commerce, forums, bug tracker, wiki) would be reasonably easy to put together. But, I think I would be better served by slowly moving all of our very specific requirements (our shop is dead simple, but has very specific requirements for the licensing of our software, for example) out to small custom tools--written in one of our preferred languages--and spend a little bit of time coding shared authentication into the best forums package and the best wiki and the best bug tracker. Since, really, in the end Joomla provides almost nothing for us but a very poor shared authentication system (poor because several of the apps have mysterious bugs that lead to some users being unable to stay logged in throughout a purchase or filing a bug) and a really bad way to update our site data--we only use the "CMS" features for five or six pages on the site, and the editor in Joomla sucks and there is no good way to use the file system for pages.

Anyway, if I had to choose a CMS today, I'd probably choose Drupal, but I think we'll end up with the non-CMS solution to our problems I discussed above. Multiple apps customized to share session data, plus a few small components written exactly for our requirements. Some of the frameworks make this latter kind of deployment easier--Django and Ruby On Rails modules can share authentications reasonably easily.

The thing is, while it looks like you're getting a lot of stuff for free from the existing CMS systems (Joomla, in particular, because it has 80 bazillion available plugins) you actually end up spending a _lot_ of time on customization and cleaning out the crap you don't need. At least, I did. It took me a couple of months to launch our Joomla site, and about a month to launch the OpenACS site before that doing the same job (OpenACS was nicer, by some measures, but it had some serious bugs that weren't getting fixed, and the architecture had become too baroque in version 5 to be reasonably customizable--too many behaviors were baked into the core libraries making it very hard to build custom tools...the docs were also broken beyond belief).

<comment><USER3> I hate to be "that guy" but can you maybe phrase that in less extraneous rhetoric?

<comment><USER2> Probably not. You should give it try, though.

</comment></comment></comment><comment><USER4> Opensource = Drupal (I think it is better than Joomla and has even been adopted by IBM into a opensource product for enterprise use)

Proprioretory = Vignette or Documentum (Both are excellent and can be used on small and really large sites with all sorts of added features suitable for online collaboration)

</comment><comment><USER5> I'm not sure what amount of time a cms would save you.

If it's a smaller site, I'd just use wordpress for easy blogging capability. All the stuff that a CMS would help you with (like dumbing down markup and such) wouldn't be worth my time, to be honest.

Depends on what you're doing though, really.

<comment><AUTHOR> wordpress might work. We don't need much since it'll mostly be a point for talking about the company... I doubt we do much with it.

<comment><USER2> "I doubt we do much with it."

If that's the case, why are you looking for a CMS?!

Since obviously no one else has told you this, I will:

Some people, when confronted with a problem, think "I know, I'll use a CMS." Now they have two problems.

<comment><AUTHOR> well maybe I should put it this way. I personally am not seeing that site as a main development focus. I honestly haven't thought too much about it. There also might be some minor parts of the site that are hard to do with straight blog technology (although I've never used wordpress). That are more designed in to cms.

but as of right now I really don't have much planned into the site.

</comment></comment></comment></comment><comment><USER6> Wordpress. Really.

Don't build one from scratch - it's a waste of your time, unless you're planning on turning it into a product later on.

<comment><USER4> WP is good for blogs but not much else in terms of general website usage esp compared to Drupal/Joomla.

<comment><USER7> Agreed - it is definitely possible to hack WP to run as a general content management system, but it is still based on the idea of a blog, and so content is still organized as "posts" and "pages" which can get old and will cause many sites to hit limitations that require more hacking to get through.

</comment></comment></comment><comment><USER8> If you like Rails, Mephisto is a pretty flexible way to get a lot of functionality for less work.

</comment><comment><USER9> It depends on the effort to build from scratch, and a marketable product.

</comment><comment><USER10> Drupal, it's not really a CMS so much as it's a framework

<comment><AUTHOR> huh... never heard that about Drupal. makes me even more interested in checking it out.

</comment></comment><comment><USER11> why not use a wiki? its simple, flexible and with the right template it does the job.

try dokuwiki it's my favorite and it uses text files for storage.

<comment><AUTHOR> wiki's are one of the most abused softwares (as in used where they shouldn't be). In fact one of our current competitors uses a wiki for what we're building custom software for. It's such a PoS, you can tell it wasn't designed for that use. We might use a wiki for internal documentation at some point.</comment></comment>


Visualizing Tensor Operations with Factor Graphs - <AUTHOR> https://rajatvd.github.io/Factor-Graphs/ <comment><AUTHOR> Hey everyone,

I've written a new blog post ([https://rajatvd.github.io/Factor- Graphs/](https://rajatvd.github.io/Factor-Graphs/)) on an awesome visualization tool that I recently came across -- factor graphs. Initially, I encountered them in the context of message passing on graphical models, but soon realized that they are useful in more general contexts.

This is the first post in a series that covers the basics and mainly focuses on understanding how factor graphs work as a visualization tool, along with a cool example of a visual proof using them. In future posts, I plan to cover algorithms like message passing and belief propagation using this visualization framework.

I made the animations using manim([https://github.com/3b1b/manim/](https://github.com/3b1b/manim/)), a math animation tool created by the amazing 3blue1brown. I built a small library, manimnx([https://github.com/rajatvd/manimnx](https://github.com/rajatvd/manimnx)), on top of manim to help interface it with the graph package networkx. You can find the code for the animations in this github repo: [https://github.com/rajatvd/FactorGraphs](https://github.com/rajatvd/FactorGraphs).

Feedback is welcome!</comment>


"Programming Gauche" published in Japan - <AUTHOR> http://www.oreilly.co.jp/books/9784873113487/

<comment><AUTHOR> shiro and i and "Kahua Project" member wote a book "Programming Gauche" which will be published from O'Reilly Japan. <http://www.oreilly.co.jp/books/9784873113487/> This book covers practical programmin technique of Scheme and Gauche. thanks.

\-- ENDO Yasuyuki</comment>


Elon Musk says Tesla will unveil a new kind of battery to power your home - <AUTHOR> http://www.theverge.com/2015/2/11/8023443/tesla-home-consumer-battery-elon-musk/ <comment><USER2> I find it useful in the event of a power outage. Other than that, the article mentions "to eliminate their home electric bill", which doesn't make much sense since the battery needs to be charged from time to time anyway... Unless of course, the battery could be used to store the energy from a renewable resource, like solar or wind power, in which case it would be really interesting. From an economic viewpoint, though, the savings should surpass in a reasonable time, the costs of buying and installing the battery, and the source of power (i.e. solar cells), and depending on the country, taxes on that.

<comment><USER3> I think that line may mean that people could charge up with the company supplied charger then go home and use it there. It's an expensive way to get your employer to pay your power bill.

In any case, I agree that it's a confusing statement.</comment></comment>


Devops Against Humanity Cards - <AUTHOR> https://docs.google.com/a/medicalinformaticscorp.com/spreadsheets/d/1OKgmjNz8l7skYfrbrOtYT6QmSf_y-BzZOWJWZC3tbUQ/edit?pli=1#gid=0

<comment><AUTHOR> Whoopise. There's actually a Github repo for this project:

[https://github.com/bridgetkromhout/devops-against- humanity](https://github.com/bridgetkromhout/devops-against-humanity)

Would a mod mind fixing that for me?</comment>


Singapore's Midlife Crisis - <AUTHOR> http://city-journal.org/html/singapore%E2%80%99s-midlife-crisis-14311.html <comment><USER2> What a great and interesting article. It's also refreshing to read that a government advisor believes that the old managerial model is outdated. While the ruling party has maintained dominance for many years, it has also brought stability to the country. Neighbouring countries don't enjoy the stability and progress as much as Singapore has. In terms of citizen happiness, which is better? It's inconclusive. People who have nothing will always want something. And people who have something will want something else.

</comment><comment><USER3> Having lived in Singapore for several years, I have sympathy, but truly the "problems" described in TFA are entirely those of the "first world". Yes, when a nation becomes wealthier than 99% of other nations, its economy _will_ grow more slowly than it did before. It's fine to encourage growth anyway, but one knows at the outset that returns to such efforts are limited.

The demographic concerns, too, would be no surprise to e.g. Europeans or the Japanese. Economies in which all the slots have been filled by previous generations, are not encouraging the current generation to procreate. Older generations are concerned, but not enough to do anything.

Ultimately, the voters of Singapore seem content with "the deal". That is, the Lee family has ruled for 37 out of the 50 years that Singapore has existed, and as the most recent elections confirmed that's exactly what the voters want. LHL is an impressive man, but are there really no other Singaporeans capable of serving as PM? If his health fails, it seems likely that his wife or brother would step forward as "regent" while one or two of his sons undergo the careful grooming and seasoning required to differentiate this dynasty from e.g. the Kims of North Korea. Any significant change to Singaporean society will only take place after its voters decide they _want_ a change.

<comment><USER4> I have been living in Singapore for the last 7 years and the peoples discontent has had some effect in the last few years. They have been increasing the requirements for foreign labour every year for the last few years. Very high property prices resulted in a similar curbs on foreigners buying residential properties etc. So people do have the power to bring change even in Singapore as far as changing the ruling party to some other is not going to happen any time soon.

<comment><USER3> The changes you mention seem pretty limited in scope. I think that's the only sort of change that _can_ occur in such a late stage of the Lee Dynasty. LHL and his heirs would be _negligent_ if they tried to introduce big changes now to how society or industry is organized. Even if they felt they knew what should happen, they are well-practiced in maintaining the status quo, not undermining it. Singapore will go through one or more "Yeltsins" before a new order that effectively governs in a new way is found.

<comment><USER4> Why would they want to change much they have been successful at what they are doing. But at the same time they are changing with the times so not to be in a position completely opposed to the majority of Singaporeans population.

<comment><USER3> Yes, "having one's cake and eating it too" is appealing in general, and I don't blame Singaporeans for wanting that. As the Lee Dynasty comes under heavier public criticism in coming decades for its authoritarian manner, I won't be one of the critics, so long as free and fair elections are still held. If Singaporeans want change, they'll eventually have to vote for it.

</comment></comment></comment></comment></comment><comment><USER5> Singapore is such an impressive city-state, but it always struck me as the political equivalent of that guy we all know, who went to a top school and became a highly performant professional but never subjected himself to a serious self-examination of his ultimate purpose in life. Singapore is a stunningly efficient country, but towards what end? Governments and cities should exist for people, not the other way around. I do still admire Singapore, and very much hope to visit some day. Great article.

<comment><USER6> > Governments and cities should exist for people, not the other way around

To a large extent I saw Singapore - for better and for worse - as a country whose sense of purpose was _entirely_ focused on existing for and achieving the ends of what its people actually want (to be much wealthier, healthier and more secure than their grandparents) without worrying too much about _means_ like political debate, ideology or caring much about heritage, national identity, environmental impact or whether William Gibson thought it was as edgy and cool as Kowloon Walled City.

I'm not sure its depoliticised, pragmatic governors whose tenure is secure unless they really screw up are really less "for the people" than the fiat of newly-elected ruling party _du jour_ whose prize for winning competitive elections is the power to decide for people based whether its core ideology is conservative or socially liberal, or indeed systems where popular will is often subordinate to upholding constitutional principles and precedents established some centuries ago.

Of course, just because death sentences for drug smugglers or retaining a token unenforced anti-gay law on the statute book are popular with the people doesn't mean they're remotely good ideas, but I'm not sure that the country examining its collective purpose would change them anyway. Government for somewhat culturally conservative people who have ugly memories of political discord and happy memories of getting a flat with actual running water is bound to take a different stance on what the people want than an competitive democracy in a long-developed country with a long-established libertarian streak.</comment></comment>


Apple HomePod – The Audiophile Perspective and Measurements: Audiophile - <AUTHOR> https://www.reddit.com/r/audiophile/comments/7wwtqy/apple_homepod_the_audiophile_perspective/?sort=top&sh=c370e646&st=JDJKCF67 <comment><USER2> To the dead comment ... _"audiophile, what does that even mean?"_

(A) reviewer explains the calibrated mic and room EQ tooling, considerably more obsessively than a typical consumer review, followed by a shockingly flat response performance from the speaker, coupled with equally unusual room EQ and psychoacoustic loudness modeling, any one of which would generally be considered audiophile features, and (B) why is 2 x balanced XLR superior to lossless digital from a digital source when it supports FLAC for instance, also considered an audiophile feature?

<comment> really-dinosaur It's not superior, but is more versatile. I'd argue the lack of any kind of analogue input gives the product a limited lifespan. I've had the same studio monitors for the past 10 years, and headphones for 15 years. Audio equipment has always been one of those things that does not get better with time.

But now we have Bluetooth headphones with hard to replace batteries, and proprietary wireless connections.

As for the flat frequency response, that's pretty cool, and the fact the user doesn't have to rent a meter and average the frequency response curves across the room (and then apply a suitable EQ), means that many of these are going to end up sounding better than most high-end speakers.

Because really, how many people who buy high-end speakers bother with room treatment and tuning?

</comment></comment><comment> really-dinosaur 'Audiophile grade'

What does this even mean nowadays? Military grade is obvious, but when your target audience thinks lifting cables off the floor with ceramic risers reduces sibilance maybe it isn't a good descriptor of quality.

Also how can something without a 3.5mm jack be 'audiophile grade'? Wouldn't it at least need 2 x balanced XLR inputs?</comment>