I always giggle when I look at the promo screenshot of fancy new to-do app that is supposed to solve the project management once and for all, and there are like 6 items on it instead of 200.
It’s simply very early on in the endless lifecycle of project management:
Simple kanban is great! It’s simple! Okay, new users, new feature requests. Wow now I’ve got a really robust product but still it only solves problems for maybe 30% of people. Let’s add more! Eventually we have converged to Jira and instead of doing a few things really well we now do everything poorly. At this point you’ve probably got enough cargo culted corporate bureaucrats using your product to survive for quite awhile as you ride the wave of revenue into the slow tide of mediocrity. Then the death and rebirth as the new starry eyed project management tool begins as YetAnotherTrelloClone
Tbf Jira is great, you just need a project manager with good opinions that sets it up and maintains it well. It turns out project management is a real skill and not a hat you put on the owner's less favourite sons.
Jira excels when there is a Jira governance committee comprised of people who actually understand data flow and are the only ones with admin privileges.
Too often some manager asks for (and is given) admin access and starts “improving” things.
Sure, anybody can create custom fields and screens and slap together a janky “workflow”, but well-oiled Jira Ops prevent an explosion of custom fields, they curate the create, browse and edit screens of each issue type to only show the fields that are important at that stage, use custom screens on workflow transitions along with validators and conditions to help ensure an issue is always in a reasonable state, etc. Then users don’t complain about the tooling.
But Jira governance takes time, effort, discussions with stakeholders, etc. And without it Jira gets a bad rap.
Jira excels when there is a Jira governance committee
True but oversimplified. Without a Jira administrative state, along with of course democratically elected Jira executive and legislature and a duly appointed Jira Supreme Court, Jira governance committees over time tend to slide into self-dealing, tyranny and eventually mass executions of anti-Jira resistance factions.
Sustaining Jira regime legitimacy over time is far more involved than simply a governance committee with its stakeholder discussions and five year plans for new custom fields.
My current company has company managed boards, 6000 devs and we have about 250 custom fields. I work in a research team and we only need Kanban and I can't change the issue type if something is created. Hell.
Jira's UX is crap. Try Linear.app, which is truly great software, equally appreciated by both software engineers and project/product managers using it.
Is this an ad? I've never heard of this and the website tries really hard to be an Apple product launch instead of showing what the tool looks like with 200 tasks on the board.
I've used it at previous places of work. It's nice. Snappier and better looking than Jira at least. One of the previous advantages of using it is that everything has a keyboard shortcut, so if you learned that you could be very efficient with it. Nowadays, however, when an LLM is shuffling my tickets around, that feature is kind of useless and I'd probably prefer Jira simply because they integrate with everything under the sun
Not an ad at all. I've been using Linear for the past 4 years. Been using Jira, Trello, GitHub Issues, and other issue trackers before. Linear is simply incredibly better compared to Jira. I had tons of colleagues in my current team and former teams who were skeptical at first, tried it, and 2 weeks later wre saying they would never come back to Jira. I've seen many similar comments here on HN over the past few years.
People can sell me layers ontop of JIRA but you can't position yourself to replace it, too much already integrates with JIRA and if you're not a startup then its a political cliff edge to try to make a case to replace JIRA.
> Eventually we have converged to Jira and instead of doing a few things really well we now do everything poorly.
Is a system that does everything within its scope well not conceivable? If it is, does systems ending up like Jira come as a result of scope creep and gradual evolution (not designing the whole thing up front with its admittedly huge scope), not enough development effort or just wanting to ship things soon instead of spending 5 years making the damn thing be good? And then, how do we get there - a Jira killer, that’d be as good as Linux (or maybe BSD) is to OSes? It’s weird that project management has either small focused tools or big ones that are also bad in a variety of ways.
A system that does too much is complex almost by definition, with complexity you introduce conflicts between features that need to be resolved through design, designing for multiple interactions of conflicting features is neigh impossible.
The combinatorial of interactions between many features will inevitably create unresolvable edge-cases that need to be patched over, either hidden away or by tacking on more complexity so the user can control how these edge-cases should be solved for their own workflow.
There is no way to do such design upfront, you can only upfront what you can think and reason about. That's how all projects start, and their demise is exactly from realising "oh, we don't cover this flow, maybe we should have a feature for that". Taking all these learnings and applying to a new system that has more design upfront starts to verge on Second System problem.
Linux is also full of cruft, it's good enough but I don't think you should live with the impression that is a benchmark of software quality. It's still impressive but as any complex system it has many issues from legacy.
Emergency Room staff are perfectly capable of putting 200+ items on a physical board. Not writing tasks down because it's too time consuming doesn't result in a more manageable workload of tasks, it results in people trying to remember and forgetting.
One of the big benefits of a physical kanban board is that the limited space means people only write down the stuff they really care to keep track of. For me it has never resulted in people forgetting anything important. It means they don't write down the unimportant stuff.
It's possible that some people would write down a lot of trivia or fantasy features, especially to start. The best response to that is to let them write the cards and then sort them according to actual priorities. But I've never seen anybody persist in that behavior very long. If they do, I think it's a sign of organization problems that tools can at best mask, never fix.
I think this can also be true of virtual kanban boards (e.g., GitHub's kanban view) if you keep people focused on the kanban view. Then they learn to focus on what's being worked on and the near-term to-do list. You can have a backlog column and let people fill it up as much as they want, but as long as you groom the top 20 cards or so to be your actual current priorities, people eventually adapt.
For software development that's perfectly fine, and probably leads to less bloat etc., but in the example given it's an Emergency Room. "Make sure patent X gets operation Y" is a bit more important than "More rounded corners?". I know these are bad Kanban tasks but in some jobs you just aren't allowed to miss and just do the things "really care to keep track of". The other stuff is important too.
Your theory is that emergency room workers would think "make sure patient X gets operation Y" so unimportant that they'd just leave it off the board? I have more faith in them than that.
There is no job where all work is equally important, where all ideas are equally good. Even in emergency rooms, where triage is a vital concept. I think it's ok if finding a new poster for the break room gets dropped because there's too much work treating patients right now.
The fundamental idea behind Kanban was WIP Constraint Management.
Unfortunately, so many people have been doing cargo-cult agile for so long that now the word "kanban" means 'task board with columns' to most people.
It should not be possible to put 200 items into a column on a Kanban board unless the team is actually shown to have the capacity to work on them without causing a bottleneck.
The fundamental idea behind Kanban is backpressure signaling for logistics.
If I understand it correctly it moves the signaling in-band so it can be handled at a locally distributed level, that is, each local parts consuming system is responsible for directly signaling it's upstream supplier to provide more parts and this is done by putting the signals on the parts bins or making the parts bins themself the signals.
I guess there is also that weird software logistics thing that appropriated the kanban term but because software logistics is very different from manufacturing logistics has little to do with actual kanban. shrugs. It's probably still a backpressure signaling thing however.
"WIP" does not work - it only seems that you are in control of the process. It may work for the same type of tasks (hammering a nail), but in my practice, where all tasks are different, it did not work anywhere.
It has worked fine for me on a variety of software projects for more than 20 years. Here's a project I documented back in 2004, where we used physical cards: https://williampietri.com/writing/2004/teamroom/
These days I'm on an all-remote team, and we use GitHub's kanban interface with WIP limits. That also works fine, and them main difference form how I worked back then is that we no longer do estimates.
I'm not sure what went wrong for you, but my strong suggestion is not to think of it as a task board. Think of it as a board that lists units of value. E.g., features delivered, research completed, messes cleaned up. We do sometimes make task breakdowns for cards, but that happens as we start work on the card, and it's just a checklist somewhere (for us currently, in the GitHub issue via Markdown checklists).
An important mindset shift for a lot of teams to use kanban boards well is to get away from siloing and toward collaboration. For my teams, cards were generally not individual achievements, but things we collaborated on.
I think it's also important for software teams to have a BLOCKED column between TODO and WORKING. The only cards that should count against your WIP limit are the ones that people are truly working on that day. If there's something you can't work on for some external reason, move it to BLOCKED. Then before a card is taken from TODO, try getting any BLOCKED item going first. It's also worth talking in your retrospectives about common reasons things end up blocked, and I like to set a pretty low limit for blocked cards to force discussion.
Happy to discuss further, but kanban approaches definitely work well for software.
I understand what you mean, but I think this is a self-deception of control. After thinking about it, I implemented WIP on the process (board), but only in the form of an "excess indicator".
Such a bold statement when you must know that countless people have a very different experience. Kanban the team methodology is about process efficiency and avoiding bottlenecks.
WIP limits are triggers to redirect resources to the bottleneck is that causes the pileup. Example: If there is pileup of PRs needing review, that is the trigger for devs on the team to stop making new PRs and switch to doing reviews.
Kanban is certainly not the best methodology for all team tasks but where it fits it works very well.
Sadly, for a lot of teams "we are doing kanban" means nothing more than "we are using a task board with columns" or worse "we have no constraints or flow controls and do everything ad hoc."
Yes, many people disagree with me. Take this as an assumption that I'm checking in my service. Of course, it is necessary to limit the amount of work, but in my opinion, WIP per column does not work. Therefore, I have implemented limits only for the entire kanban board (process).
I remembered one project I added over 20 items and then GitHub’s Kanban started freaking out. Never did I used it since. Trello was great but got heavier too with all those fancy stuffs and colors.
I’m still in the lookout for a great kanban software though.
A lot of Ukiyo-e wood prints have small details that mean a lot to locals. I enjoy learning about them on the NHK's English channel.
In this case, the boats are fast (each has a bunch of crewmen) and were used to catch valuable fish. And the boats on the right have two people not at work (barely discernable in TFA's recreation). Those people were on break, getting ready to replace tired oarsmen. That way, the boat could be moving at all times.
I thought so too, but the phosphine signal turns out to be small but real. What everyone involved in the back and forth debate over it agrees on is the need to send better sensors.
For resin printing, doing it yourself almost never makes sense. It’s expensive, fiddly, messy, hazardous to your skin and lungs, and consumes a lot of space to do right.
Filament printing, on the other hand, makes sense to do yourself quite often. A $200 printer will do an excellent job of most things you can throw at it, it doesn’t take up much space, is quite safe unless you’re using weird filaments, and even a kid can learn the basics in a couple days.
I made myself plugin that shows new news in wikipedia's current event page and I was using levenshtein originally (they often edit couple of words in article over span of few days so I compare each new article with previous ones for similarity) but after few days it became too slow (~20s) because O(m*n), so I switched to sorensen-dice instead which is O(m+n) and it's much faster and works very similar way, even tho they do slightly different thing.
You need to go back to the roots of open source. Fork it, merge your two changes, remove 90% of code you don't need, rename it, write article about speed up in the new successor vs the old thing.
Forks don't have to be hostile. A perfectly reasonable way to react to an overwhelmed maintainer is just to do a friendly fork. Keep the original name, attribution, git history etc, update the README and start acting as a trustworthy lieutenant. You can review stuck PRs and merge them into your own branch, whilst also merging with upstream master. After a while if you seem to be making good calls the original maintainer can do a bulk merge from your branch to bring in many PRs at once, and maybe add you to the repository.
Check out my fork, Jellyden(iro). It’s the best way to watch Heat 2. All the media selection garbage is removed for a streamlined Heat 2 experience, because why would you want to watch anything else when you could be watching Heat 2 instead.
It's worth asking "if AI is so great for software development, won't that make it dramatically easier for people to maintain their own forks of software?"
(I suspect the answer ends up being no, but the reasons could be interesting)
I'm curious why you think the answer would be no. I've had some success with resolving complex merges with GPT 5.4, and it seems obvious enough that AI is a good solution for maintainers who don't have anyone they can trust to take over the project whilst also needing to boost throughput.
I've been using 5.4 recently, and even on "extra high" some of the tests it wrote were opening the source code and doing a regex to confirm the presence (or in some cases the absence) of specific substrings. It wasn't running the code to confirm behaviour, and the regexes didn't even do a basic check to confirm the text wasn't commented out (not that it would've been sufficient if they had, this is just to illustrate how bad it was).
So, yeah. I'd guesstimate this model was fine 75% of the time, mediocre 15-20%, and actively bad 5-10% of the time. How valuable it is depends on how much energy you can spare as a human on spotting the bad.
You jest, but I think there is kernel of truth here. I do think people should be doing more (friendly) forks instead of funneling everything through upstream.
Ultimately if the new contributor brings in others to the project to also review and progress the project then it will quickly outpace the development on jellyfin and become the successful fork. No maintainer can cope with the workload of something like jellyfin and if they wont assign maintainers there isn't much else to be done.
The key to the success is dealing with the outstanding merges by bringing maintainers onboard that are trying to contribute, build up the team and then the merges will get processed a lot faster.
So this is exactly what's unintuitive about queues, an analogy would be car lanes. Intuition might lead you to conclude that if a 2 lane road has traffic constantly going to 4 lanes will solve the traffic. But this is not true. Many people that would have used the road might have been using public transport or just decided not to commute or stay inside normally will join the traffic until it once again equilibriates. Adding more maintainers without addressing the core problems of the queue won't lead to success
If you only focus on "solving the traffic" then you're right, adding more lanes ultimately just leads to more lanes being full. But the overall throughput is much higher! We need more holistic solutions, to be sure, but I hope no one thinks that means I-5 around LA could just be 2 lanes of traffic because they'll be full of traffic either way.
Does induced demand apply to open source maintaining? What would be the mechanism for that?
For traffic, more users note that the highway is easier to drive on and come over. Would people notice development speeding up and start adding more issues?
Just today I improved my record to 18 minutes. Btw, I noticed my juggling is completely subconscious, I don't move my hands voluntarily where the ball is, the hands move on its own.
reply