I bet half of their R&D is being spent to figure out how to do Kubernetes the right way.
Asana S-1
171–180 of 251 posts
Re: Asana S-1
#172Based on a few of the comments on this thread, I wanted to point out that filing an S-1 is not something that you just do overnight. When companies decide to go public it's a lot of work usually involving multiple dedicated teams on the business side. It takes many months and can take over a year. So while the timing here is interesting, nobody decided on Friday that many well-known tech firms would declare their int…
No, they decided that 6 months ago (or whatever the lead time is), but everyone decided at the same time, for fairly obvious reasons.
This is false. A lot of these companies started their IPO process earlier but then got delayed due to COVID. Not everything is as pessimistic as you’re making it sound. It just happens to be before November (companies usually dont go public during election season) so this is the only viable window for companies to go public for the remainder of the year.
Re: Asana S-1
#173Earlier quoted context omitted.
"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.
I didn't believe that was an actual quote from the article until I read it. It sounds like a joke and I can't imagine anyone reasonable would say that. There are definitely good reasons to build your own framework but performant and stable applications isn't one of them. Usually it's a solution looking for a problem.
By this logic nobody would ever build a framework designed around performance and stability?
Re: Asana S-1
#174Earlier 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…
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.
Re: Asana S-1
#175Earlier 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 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…
Good luck now having to build and maintain software that needs to reliably and correctly update itself on +70K instances not under your control.
That's not even taking into consideration the fact that you no longer quite know what's going on in those 70K instances, which leads to extremely rigorous tests or the need for a big support team.
It would be interesting to know what costs the Jira self hosted option has put on the product for comparison to Asana's running costs.
Re: Asana S-1
#176Wow, 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…
I bet half of their R&D is spent to figure out how to do Kubernetes the right way.
Re: Asana S-1
#177Wow, 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…
> 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 native services which scale pretty well more or less out of the box( you still domain knowledge I.e. need to know that service’s unique limitations)
scaling it for cheap is harder, still not as hard as it used to be, plenty of mature tech is available today. Ironically devops engineers with modern cloud skills generally are more expensive than the ones who know how to stand a server in a DC.
A lot of startups like WhatsApp , Instagram built great products at scale with less than < 50 so it not impossible to achieve
Re: Asana S-1
#178Earlier quoted context omitted.
This is a hell of a market to short anything. In the near term anything that helps remote work like this is probably going to spike up. Good luck with that. I know that I wouldn't personally be comfortable being confident I could make collateral to outlast a bubble or guess correctly when the tide is going to turn to make money off of an option trade when it comes to a remote enabling company in a stock market as cra…
Not really - considering the massive premium a lot of "remote" tech stocks are getting I'm surprised that Slack ($WORK) is basically going nowhere. Asana is closer to Slack than other cloud stocks imo, and given Slack's mediocre performance could easily see the same thing happen with Asana.
Slack's not sexy. Slack will always be what it is, and a dongle or peripheral isn't going to improve that core product.
Similarly, there is no iPhone or GoPro waiting for unleash Asana's potential.
Needful stuff.
Re: Asana S-1
#179Earlier 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.
just use nodejs
Re: Asana S-1
#180Wow, 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…
There's always a comment here on HN wondering why company X has so many engineers for such a seemingly simple product. The answer is, unsurprisingly, not that they're terribly inefficient. Rather it's that running a popular service at scale is hard, the long tail of features is really a long tail, and a lot of effort goes into even simple things because small differences really add up when multiplied by large N.
This is a big part of it, but I wouldn’t downplay the inefficiency too much. A pattern I’ve personally seen:
* Small team of 5 devs and maybe 1 manager working on some large area of the product is very efficient
* Startup is growing users/revenue very fast, attracts big VC investment
* Major hiring, a year or two later that same area of the product has 30 devs, 5 product managers, 5 dev managers, 3 designers, a manager of the dev managers, a manager of the product managers/designers, and a manager of the dev and product managers
* There’s too many cooks in the kitchen, nobody feels empowered to make decisions, meetings multiply like crazy, every decision takes exponentially longer to make than before
* Instead of planning 1 sprint ahead, you start doing quarterly plans, 3 year visions, customer facing roadmaps, etc. “Predictability” becomes more important than productivity
* Teams know that only predictability matters, so they start making really conservative estimates, just to be safe
* If you have 2 months to do 1 month of work ... it’ll take 2 months. And this starts becoming the new norm
* Plus, you start spending more and more time planning, “scoping out epics”, etc., to get “better” estimates
You get the idea - pretty soon that 45 person team ships not much more than the 6 person team used to. Nobody is purposefully dogging it, or trying to go slow, but it happens when companies grow unless you’re really, REALLY good at fighting it. And few companies are. Everyone is BUSY, but they’re busy doing quarterly plans, “full potential analyses”, change management, meeting with stakeholders, working on all sorts of checkboxes to get all sorts of security certifications to sell to one or two big government buyers, working on “business development” projects that users don’t care about, etc.