Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Asana S-1

sec.gov

Post reply on HN
Print view View original

181–190 of 251 posts

Re: Asana S-1

#181

Post by tlrobinson »

phaedryx wrote: post #86
aaronbrethorst wrote: post #78

Earlier quoted context omitted.

Costs a lot of money to build your own programming language and then throw it out. https://blog.asana.com/2017/08/performance-asana-app-rewrite...

"Our founding engineers had learned from their experience working at Google and Facebook that to ensure a performant and stable application, they would need to build their own framework" Wow. Interesting.

Keep in mind, Asana was founded in 2008.

Luna had some of the same concepts underpinning React, about 5 years earlier.

Re: Asana S-1

#182

Post by aahortwwy »

manquer wrote: post #177
PragmaticPulp wrote: post #62

Earlier quoted context omitted.

> How does a team grow to ~300+ developers ($89M R&D) to figure out how to attach PDFs and videos to tickets, and email people when there's a change in status? As with most of these companies, user-facing feature development is only a small part of the engineering workload. I would assume the majority of those engineers are working on less visible tasks: Devops, build systems, infrastructure monitoring, security, bac…

This is common reason cited . I don’t disagree as such, as my own product grows I see it happening . However I am not sure how much is strictly necessary . I honestly think a small team could achieve lot more . You loose the agility of smaller team at >50 have large company problems without the benefit of sheer manpower 500-1000 typically brings. Scaling devops is not as hard as it sounds . There are plenty of cloud…

A major reason why engineering teams at these sorts of companies grow so large is because of how quickly the business operates and the company's rate of growth. These factors put the engineering team in a position where they're constantly having to choose the faster, easier option in the present despite the fact that it will produce a lot more work for the team in future. When the future rolls around they're still under the same constraints so they hire more people to deal with the problems caused by their past decisions while making the same kinds of decisions in the present. Rinse and repeat for several years as the company grows into a behemoth before going public.

One interesting thing to note is that as these constraints relax (business stabilizes, growth slows) the engineering teams can make better decisions in the present, clean up the decisions of the past, and reduce their overall need for people. If the company has built a money-printing machine the redundant people are then moved to new lines of business funded by the money-printer. If there's no money-printing happening, margins are super thin, and there's an incentive for the company to cut costs... where do those people go?

Re: Asana S-1

#184

Post by 1290cc »

Makes sense they're going for the IPO at the start of the work from home era. Asana has been around awhile and my team always used it for remote team communication and project management. We never saw the need for apps like Slack or Basecamp because working with the tool is very similar to the Getting Things Done system (or Toodledo).

Re: Asana S-1

#185

Post by core-questions »

dmart wrote: post #44
godot wrote: post #34

Earlier quoted context omitted.

Do you have up-to-date experience on both? I ask because, this year is my first time using Jira in 10 years. I was in big corp 10 years ago and we were on Jira and it was a disaster to have to use. UI was a mess and it constantly went down or went slow (big corp; self-hosted.). My current startup started using Jira Cloud recently and I found it to be much better than my past experience, and better than Asana. I last…

This was about 2 years ago - at that time I found both Asana and Jira to be similarly slow, so kind of a wash in that regard. But it was corporate self-hosted Jira, so perhaps Jira Cloud is a smoother experience.

Jira self-hosted is actually often a lot faster than Jira Cloud, if you have decent gear to run it on. You run the database too, so it's a matter of how much cash you want to throw at it. Jira and Postgres on decent storage can be pretty quick, though of course it's still 100x slower than any normal 1990s desktop app.

Re: Asana S-1

#186

Post by bryanrasmussen »

sujinge9 wrote: post #119
dcolkitt wrote: post #111

Earlier quoted context omitted.

This makes a lot of sense. But in some ways it shows the downsides of the modern obsession with SaaS. How many of those jobs would be required if Asana was simply sold in a shrink-wrapped box that you installed on your desktop or the downstairs server run by the corporate IT guy. In some ways SaaS is a big win because it offloads all those tasks to a centrally hosted service. No IT guy or tower server in the corporat…

Sure, but it's economies of scale. You only have to do the hard stuff once at the source, instead of having every node do it individually. Also if stuff goes wrong in the node model, the customer will blame you even if it's mostly their fault. So it's also important for brand benefits.

On the other hand if stuff goes wrong in the centralized model it goes wrong for everyone everywhere, and it almost certainly is really your fault.

I agree trade-offs, but I sometimes feel the gain has not been all that great.

Re: Asana S-1

#187

Post by nlitened »

keepingscore wrote: post #91
dmart wrote: post #18

I've found Asana to be a much, much nicer product to work with than Jira (at least as a developer, not sure about from the management side.) I genuinely wish them success and hope they're able to grow their marketshare.

Ooof I'm on asana for the first time after using jira for 10+ years. I hate it. Asana is a generic workflow tool where jira leans towards software development. This means that every part of your process you need to create in asana then explain to your team this is the one true way to use asana. Example Epics. A way to roll pieces of a project into a larger ticket describing that project. There's no concept in asana.…

You could make a project for each Epic, and assign tasks to them as well, so you can have them both grouped by Epic and in one place at the same time.

Re: Asana S-1

#188

Post by jmnicolas »

AlphaSite wrote: post #174
freehunter wrote: post #143

Earlier quoted context omitted.

If it was shrink wrapped software they would need a bigger sales team, a bigger support team, a bigger professional services team, etc. It’s just trade offs.

And honestly its actually even more work in many ways, since you need to be able to work anywhere, not just in a well known environment.

In the age of VMs and containers I'm not sure it's still true.

Re: Asana S-1

#190

Post by raviisoccupied »

tempsy wrote: post #51
supernova87a wrote: post #16

Wow, this is a torrent of IPOs today. Investors / boards are wanting to get money out before things turn south I feel. Aside from that, I'm surprised how much it costs Asana on engineering R&D, for essentially a ticket management system. How does a team grow to ~300+ developers ($89M R&D) to figure out how to attach PDFs and videos to tickets, and email people when there's a change in status? (ok yes I'm oversimplify…

Very crowded market - not very sticky either relative to other SaaS type cos. I would avoid this one personally.

Interesting, I would say that once an organisation has gone a year or so with Asana, they are very unlikely to move as it would involve creating new processes and re-skilling non-tech savvy colleagues, therefore making it incredibly sticky. Which SaaS companies would you say are more sticky than this?
Post reply on HN