This article would be more accurately titled, "Why you shouldn't try to build a venture capital funded business." Of course, my suggested title is not nearly as compelling and edgy as the actual title, and would be less likely to make it to the front page of Hacker News.
The content in the article isn't inaccurate or misleading per se, but it's also basically repackaging well understood information about the economics of startups and venture backed businesses.
Further, the author asserts that, if you're trying to optimize your personal economic outcomes, you should not pursue venture funding. But this wrongly assumes that money is the sole motivator people have for starting a business. Further, it ignores the massive economic value that the venture ecosystem has created.
Some people want to retire early. Some people have bigger ambitions. Neither group is right or wrong, but, if you're starting the business, you should know which group you're part of.
I have a friend that's super smart, currently works in biotech, and studied computer science, would you be interested in chatting with him about possible applications? Happy to make an introduction if you like!
I know I’m not Simon but I’ve been in this space for a while and would love to chat with your friend about what applications they’re thinking about and how they’ve been solving this problem at their current company.
Are launch congratulations in order? If so, congratulations! I'm super excited to see where you take this, and I hope you're able to find a solid business model to support you and your work.
History is littered with dead startups that designed for scale before they had enough usage to justify it. Within reason, having users knock your site over resulting in failures like the Twitter Fail Whale is a good problem to have.
With that said, you need to be prepared to scale up quickly once you have this problem. There's a reason Facebook counts its users in the billions, and Friendster is a footnote in internet history.
Yes, but.. I am a software architect. ~90% of the job offers I get are from CEOs/CTOs who want me to join their small company to help them refactor because they can’t grow anymore. Tech debt kills as well.
Is that a "but" or is that how things should work? You solve a problem when you have it or can reasonably predict it (in technical/engineering terms). I also think it's sensible to look for experts when you need them right?
I don't know I've been places where the difficulty scaling and failure to do it promptly posed an existential threat. As in "this system is poorly designed and needs to be rewritten so we're going to pause new features for six months to do it", you can't always just magically find an expert to solve your problems in a timely manner, and feeding the technical debt monster can easily kill startups.
If they have the money to hire you and they have pent-up growth that refactoring will unlock, that really sounds like close to an ideal path for a startup to take. They're literally paying down their tech debt by paying to hire you. Maybe ideal would be a little earlier so it doesn't block growth, but yeah. In my experience way more startups have died from premature optimization
So how do you square they circle "Don't design to scale but scale up quickly when you need to"? You can't rewrite your stack just because you took on a new customer that is suddenly killing you.
I don't think that it's stupidly hard to get basic things set up for scaling at the start. These don't apply to everyone but:
- use a cloud provider, they let you grow
- write infrastructure as code (terraform, pulumi, cdk), it's not that hard and it makes building your 2nd, 3rd data center easier
- for the love of God think for 10 minutes about a scalable naming convention for data centers, infrastructure components, subdomains, IP ranges etc. This type of stuff causes amazing headaches if you get it wrong, and all you have to do is consider it at the start. Many AWS resources can't be renamed non-destructively, and are globally namespaced. Be aware of this. Don't paint yourself into a really stupid corner.
- even if you're not doing microservices, consider containers and an orchestrator that has scalability baked in (like Kubernetes). If you use a managed Kubernetes with managed node groups or fargate, you can basically forget about compute infrastructure from this point on
- deploy Prometheus, Grafana, Loki etc day one and build basic dashboards. With Kubernetes, you can get this installed quickly and within a day you'll at least be able to graph request/error count and parse logs.
- deploy an environment for developers to deploy to and use the product (even load test it)
The development cycle is now set up for building what you need to build. You can easily find developers at any level who have experience with containers, Kubernetes, Grafana so they can onboard quickly, be productive and troubleshoot their own stuff. They can refactor the monolith without having to invent service discovery, load balancing, ingress etc.
My personal experience with Kubernetes began at a start-up with a tiny team, none of whom had prior experience with it. We had started building a single monolithic app. But within a short time we figured out how to make a helm chart, add ingress and boom, we were "online". Every time someone was about to spend time and effort inventing something, we would quickly scan through the Kubernetes docs and CKAD material to see if we could avoid having to build it at all. We leverage cloud stuff too, where it was cheap and easy and scalable (like AWS SQS/SES/SNS/CodeArtifact/ECR/Parameter Store)
i didn't see the words "it depends" anywhere in this
thats the whole point of engineering, picking/building the right solutions for the problems and context
some stuff just needs a vps, a php file and an sqlite db and it will scale
other stuff might need container orchestration or anywhere in-between (or beyond). it should depend on the context though and we should be prepared to change strategy as needed
I did say "These don't apply to everyone but:" and then gave my generic list of stuff that works for a lot of people.
I get that some people can just run a single go binary or whatever. The ones that don't, need to set themselves up to grow easily when they need to. Having some sort of basic plan or framework that doesn't take more than a week to set up is due diligence, and hiring (when your need to) will be much easier.
Is one of the problems though is that the early audiences appreciate this kind of over-engineering? If your investors/buy-in folks are being shown early demos and you mention "and this thing is gonna scale seamlessly up to 1,000,000 users because of tech words A, B, and C" then they get excited. They don't understand A, B, or C. But what they just heard is that you're planning for Big. And that stokes their aspirations.
Facebook is a great example. They did tons of things not traditionally known as highly scalable. Like one repo with the project coded in php which was largely a monolith.
And an imperative codebase which looked like something out of Matt's Script Archive. I often wonder whether a startup today could pull-off something similar.
I'm not sure. The bar for UI has been raised significantly since Facebook launched and mobile has changed the game to such an extent that you need a presence on 3 platforms out of the door (iOS, Android & web) to even stand a chance.
Not entirely true for many apps. The app I work on does not need a working mobile site, because we don't think our consumers are going to use it on mobile.
However, we do very much care about our UI - and I think react at this point helps with that. But I don't think React complicates the stack too much. It may even make things easier, tbh - I don't have to test pages on backend tech, just endpoints.
React easier compared with what - imperative PHP4 at Facebook in 2004? I'd have to disagree. React state management is much heavier than returning HTML from an embedded PHP template.
This looks really neat. One thing I noticed on reading the source code, it appears to actually import the modules:
Quoting the docstring on the `track_module` function:
"""This function executes the tracking of a single module by launching a
subprocess to execute this module against the target module. The
implementation of thie tracking resides in the __main__ in order to
carefully control the import ecosystem.
> I think this is clever, and maybe even necessary, but feels risky to do on unaudited third-party Python libraries.
This is why my coworker built the project he called "dowsing"; it tries to understand as much as possible from the setup.py's AST, without actually executing it.
Hi, I'm the main author of import_tracker. Thanks for taking the time to dig into it! It's a really interesting point that the subproces.Popen could itself be a security concern. The command that's being executed is executing the __main__ of the import_tracker library itself (which is not something that a user can't configure), so is your concern that import_tracker itself is untrusted and might be a concern for users running this on their machines?
For context on why I'm using the suprocess here, this allows the tracking to correctly allocate dependencies that are imported more than once (think my_lib.submod1 and my_lib.submod2 both need tensorflow, but my_lib.submod3 doesn't).
Hi! I think that, in my cursory reading, I misunderstood what the code is doing. I thought it was importing the module you're trying to analyze... I'll have to read more closely when I have some spare time.
Makes sense! I think the commenter below correctly addressed the true security concern here which is importing arbitrary python libraries. As is, import_tracker doesn't attempt to solve this problem (though it's an interesting one to consider for this or a similar library). Please feel free to reach out with any other questions if you're curious.
No, you understand. Indeed, by importing Python code, you execute Python code, and so there could be ab execution path for malicious code to run.
FYI, pylint does something similar for native-code extension modules (unless this changed in the past few years): it imports them dynamically!
EDIT: reading the code more closely and reading the rest of the comments, more precisely, it's not the subprocess call itself, but rather importing an arbitrary Python module, which could be a path for code execution. But this is the case generally with Python: importing a module executes code, and so even just importing (not otherwise executing) an untrusted module could be problematic.
Yep, this is spot on. As written, import_tracker does indeed do a dynamic import of the library in question and you're right that this introduces the possibility of arbitrary code execution. Currently, import_tracker is designed for library authors where the library in question is a trusted library that has dependency sprawl.
It's a very interesting use case to consider how a similar solution could work as a sandbox for investigating supply chain concerns with third-party libraries that have transitive dependencies. I think some of the static analysis tools referenced in other comments would address this better since the real concern there is detecting the presence of transitive dependencies which may be malicious as opposed to identifying exactly where in the target library those dependencies are used.
Love Figlet, we used to use it frequently on the shared unix machine where members of the Berkeley Computer Science Undergraduate Association (CSUA) would hang out: https://www.csua.berkeley.edu/
I don't think it's been a thing for years and if you ask me, it stopped being a thing when the old Sequent Symmetry went. Not only non-root users could wall, remote users could wall. A smaller, sillier internet.
I respectfully disagree. There was a vibrant community on soda well into the early aughts, even if it was running FreeBSD on x86 vs. some older more esoteric hardware architecture.
It's good to see that the CSUA encyclopedia still exists somewhere, even if it's not hosted on soda anymore:
https://www.erzo.org/shannon/writing/csua/encyclopedia.html
I had the good fortune to meet and work with the primary author at a small games company called Skotos Tech during my later undergraduate years.
I mean, I'm not being entirely serious but it was kind of the beginning of the end as shell accounts became increasingly pointless. Although maybe my mental timeline is a bit off, I remember a lottery scheduler getting implemented on the FreeBSD soda and those writeups seem to be from the late 90s not early 00s as I thought.
The t-shirts used to be a good way to run into strangers IRL who would inform you that they too partied with Nick Weaver.
Yes, I partied with Nick Weaver. The lottery scheduler was implemented in the late 90’s, but soda’s kernel ran with the lottery schedule well into the aughts.
I agree that shell accounts weren’t as important by the aughts, but the culture was still going strong in the early aughts.
The content in the article isn't inaccurate or misleading per se, but it's also basically repackaging well understood information about the economics of startups and venture backed businesses.
Further, the author asserts that, if you're trying to optimize your personal economic outcomes, you should not pursue venture funding. But this wrongly assumes that money is the sole motivator people have for starting a business. Further, it ignores the massive economic value that the venture ecosystem has created.
Some people want to retire early. Some people have bigger ambitions. Neither group is right or wrong, but, if you're starting the business, you should know which group you're part of.