JIRA and its interface is incredibly slow in comparison. An extra 30-60 seconds per task to create assign and organize
Seconds makes (billable) hours. I recommend JIRA for all my consulting work.
(I jest, I jest.)
Ask HN: Has any of the Pivotal Tracker replacement attempts succeeded?
21–30 of 45 posts
Re: Ask HN: Has any of the Pivotal Tracker replacement attempts succeeded?
#22> People say Linear is fast but it's nothing compared to how well Pivotal worked. My company switched off Pivotal Tracker because it would slow to a crawl and require several seconds (!!) to load the page, with individual actions causing a DOM cascade that frequently hung browsers. Maybe it worked at small scale but it definitely didn’t work at a large scale.
Oh so you mean mandatory pairing (which does away with the deep thinking required for some algos) and requiring "clean code" and other Uncle Bob BS doesn't contribute to actually scalable and efficient code?
Color me shocked
Re: Ask HN: Has any of the Pivotal Tracker replacement attempts succeeded?
#23I still like redmine
Redmine was pretty great.
Re: Ask HN: Has any of the Pivotal Tracker replacement attempts succeeded?
#24I run https://bye-tracker.net and am also working on https://lanes.pm (still closed beta but open for more users soon). I just retested all of them and it really seems none are fully usable. I also see few improvements since April, it seems many of the teams either burned out trying to finish in time, were overwhelmed seeing what it really takes to make the details work after the fun parts are over or were disappointed seeing how low user numbers are from direct switchers.
I disagree with your 2010 theory, back then it would have been even less fruitful to make a viable alternative with the limited time and resources available. Especially as things like the UI state handling and some of the architecture was unheard of back then, years ahead of its time and even linear now does not fully match many aspects.
Similarly "Any half-skilled indie dev could have made a killing on making a good replacement" is just wrong, a) you need to be a really great developer to make something that even nearly matches PT, there is more than is obvious to someone not deeply familiar with the internals of the product and 15 year of refinements that went into it. A few of the cloning teams were some of these indie developers who thought it would be fun and easy which was obviously very naive.
b) "Make a killing" is equally misleading. I would be surprised if its possible at all to break even on something like a pure PT clone. There are maybe 200 original users who are super loud and "in love" but this can easily mislead to thinking there are millions of users that would be immediately jump on and start paying. It takes probably 2 orders of magnitude more addressable market to make the financials work just by providing a PT clone (Which is why lanes.pm is focusing on making what tracker would need to be today not just catching up on what it was.)
Just give it a bit more time, there are at least 2 teams including lanes working on this and we all decided not to launch something half baked and buggy that loses your data.
Re: Ask HN: Has any of the Pivotal Tracker replacement attempts succeeded?
#25Pivotal was far from a perfect company (if there can even be such a thing to begin with), but sadly, a lot of good things were lost in its latter days. This was one of them. Are there particular attributes, behaviors, or properties you feel are important that you can't find elsewhere? I see you mentioned latency, for example — what else is key to you?
We have a page dedicated to what was special. You can read the descriptions in the hero section here: bye-tracker.net
Re: Ask HN: Has any of the Pivotal Tracker replacement attempts succeeded?
#26If you continue to not find what you need and are willing to be a subject matter expert on what Pivotal actually is (because I never saw it), I would be interested in building this. A lot of people share your sentiment so it could be successful, but it's hard to clone something unless you know the thing.
Please not yet another failed clone attempt. If you never used it, you have absolutely zero chance of replicating it, its something you need to have experienced.
Re: Ask HN: Has any of the Pivotal Tracker replacement attempts succeeded?
#27My partner built Velocity Tracker [1], not a clone but it aims to implement the core philosophy of Pivotal. Any and all feedback would be most welcome. [1] https://app.velocitytracker.co/
1. Google Login, please.
2. Screenshots.
Re: Ask HN: Has any of the Pivotal Tracker replacement attempts succeeded?
#28We use Zube.io these days. Everything is just a GitHub ticket under the hood, it just slaps a PM friendly UI on them. I'm a fan.
Close, but not PT. PT doesn't have the concept of status columns. It is effectively in the active running iteration, or it is in the backlog. What fits in the running iteration, is based on velocity.
I love that it is just GH issues under the covers though, that's smart.
Re: Ask HN: Has any of the Pivotal Tracker replacement attempts succeeded?
#29> People say Linear is fast but it's nothing compared to how well Pivotal worked. My company switched off Pivotal Tracker because it would slow to a crawl and require several seconds (!!) to load the page, with individual actions causing a DOM cascade that frequently hung browsers. Maybe it worked at small scale but it definitely didn’t work at a large scale.
Oh so you mean mandatory pairing (which does away with the deep thinking required for some algos) and requiring "clean code" and other Uncle Bob BS doesn't contribute to actually scalable and efficient code? Color me shocked
I used to think the active pairing was just a fad or crazy talk. Then I went and worked at Pivotal and learned it first hand. The way they did it works.
Re: Ask HN: Has any of the Pivotal Tracker replacement attempts succeeded?
#30> People say Linear is fast but it's nothing compared to how well Pivotal worked. My company switched off Pivotal Tracker because it would slow to a crawl and require several seconds (!!) to load the page, with individual actions causing a DOM cascade that frequently hung browsers. Maybe it worked at small scale but it definitely didn’t work at a large scale.
That's weird. Pivotal itself had hundreds of developers using it for what was thousands of projects. It was never slow like that for us, unless they were having some sort of outage or something.
I hate to say it, but my immediate guess is that your company was using it in some fashion that it wasn't intended for. That was the real problem with the tool. Unless you actually worked at Pivotal, you never really got to learn how to use it the way they intended. The documentation was good, but nothing beats going to the source.
What is your best guess for why it got so slow?