1. 35

    Startup mistakes are spending too much time thinking about data stores, and not enough time thinking about making money. Personally I believe that so many startups fail because they obsess and re-engineer their tech stack so much. Most startups (if they ever get to making money) change their initial product/offering so much by the time its out there, that the tech stack decisions they made in the early days aren’t as relevant to the problem they actually end up solving. Use a sane default then evaluate if you actually need anything else. So I whole heartedly agree with his statement just use Postgres, and you won’t regret it.

    1. 3

      I agree with you after reading lots of Hacker News and Barnacles. They should spend almost all their time marketing, listening to customers, building/testing features, and so on. That said, it’s still good to consider this stuff ahead of time to give them templates for what to go on that will reduce operational problems early on and/or in maintenance down the road. Like the OP and your Postgres recommendation. Also, like turnkey Postgres appliances for the cheap hosts they’ll probably be using.

      1. 3

        100%. I been in numerous failed startups. I’ve seen plenty more. Datastore wasn’t an issue even once…. I’ve seen plenty of startups build on amazing datastores and fail to have any sales and marketing. I’ve seen plenty fail from not having backups, from hiring poorly, from overreaching.

        Datastores can hurt when you’re scaling up. But you’re scaling up now. Congratulations.

        Agree that defaults make sense. However, equally it’s worth being aware that you’re going to have scale problems whatever you do. Every serious relational database I’ve seen is a beast. Comes with the territory.

        1. 2

          Yup, going with Postgres at the beginning makes sense, because it gives to freedom to experiment and iterate on your domain in the beginning from a solid foundation. Alas the databases that are more geared towards scaling are currently trickier to work with in the face of changing requirements, so mistakes become magnified to quite a large degree. But you’ll eventually want to move to a different model once scaling becomes an issue.

          At the moment my thinking is that you use a RDBMS under the hood, but pretending it’s CQRS/ES, which maintains an nice separation of concerns between reading and writing and the persistence layer, then you are in a better position to switch to something more scalable in the future, whilst maintaining the advantages of in-place migrations in the beginning when requirements are still up in the air.

          1. 1

            I had never heard of CQRS before, it’s quite interesting. Could you elaborate a bit on ES?

            1. 1

              Event sourcing…

              And I’m with /u/brendan on this: focus on the “why” (design) of separating concerns, not the “how” (transport). It’s a long time between MVP and having load that demands Kafka, RabbitMQ, NSQ, NATS, etc. There are designs that need those early but I squint hard at that because they add a lot of complexity and operational overhead when you’re still figuring out how to solve other problems.

        2. 3

          Startups don’t exist to make money- they exist to get bought. That’s their profit model: get bought out at a high valuation before your burn outpaces your investment.

          1. 5

            Startups don’t exist to make money- they exist to get bought.

            To be fair, their ability to get bought should depend on their ability to make money, and after these crazy bubble times are over, it will.

            That’s their profit model: get bought out at a high valuation before your burn outpaces your investment.

            That’s not a profit model though :) It’s a plan for making a return on the time, effort, and money the founders invested in the startup. It’s a gamble too!

        1. 2

          This is super interesting - and it caused a lot of emotions to bubble up on reading. I’ve never been a spectacular coder. But I’m a terrific engineer (very imho). This has always been a conundrum for me.

          The emphasis now is for “full stack developers”. However, stacks are getting very, very unique. I’ve never really seen two the same.

          Nobody will know your stack. It’s much better to have someone who can navigate your stack. We put so much emphasis in hiring on writing code, but never how good people are at reading code.

          Additionally, we put so much into “expressive” languages now. Programming Ruby isn’t Ruby. It’s a bunch of DSLs that you need to get your head around. The magic of Rails was they somehow assembled a bunch in one place.

          1. 2

            I’m assuming this is because the native browser experience is always going to be better than a non-native one - especially on Android.

            The issue then is broader than “engine diversity” - it’s the Android-iOS platform duopoly.

            1. 6

              Culture makes and breaks co-located work too!

              I’ve discussed this a little with people from Automattic, Zapier, Buffer, etc. There are a lot of advantages to remote work. However, it’s an obsession for these companies. That’s what makes it work. I’m not against partial-remote organizations, but it still needs to be an obsession. It’s hard to do one. Really hard to do both.

              One other key thing - Take a look at the career pages for these companies. They usually show employees all getting together in Austin or Costa Rica or somewhere. Part of making remote work work is also getting together regularly. You come together every few months, thrash everything out, then break out into your remote again. So face to face is still a valuable component of these models.

              1. 3

                Usually you want to tag this sort of thing with release, and given its source maybe finance–that said, it’s still just a press release from a bank. :(

                1. 1

                  Will do!

                  Realize it’s just a press release. My first career was in banking/finance tech, so I have a lot of nostalgia for this stuff. Back when I got started finance was the most interesting place to do tech. Sadly that waned over the years. So much good stuff has been locked away. I feel this could be a really powerful trend. So quite exciting for me.

                  1. 1

                    Back when I got started finance was the most interesting place to do tech.

                    If you feel like sharing, I wouldn’t mind listening: around what time was that? And what niche of information technology it was that made investment firms an interesting place to work?

                    1. 2

                      I came it at the beginning of the end - the late 90s.

                      Late 80s/90s Tech was a core competency of banks. By the time the 2000s rolled in, Tech was seen as a cost center - a way to save money by cutting costs. Rather than a source of innovation.

                      Part of that was the rise of Java and the Web. Part of it too was the inability to adapt. That said, Mainframes, Queues, Virtualization, Integration, High Speed Databases. All that stuff was quite mature and in widespread use.

                      1. 1

                        Thanks for sharing. I can see how that would be an interesting environment to work in, with interesting problems to work on.

                1. 6

                  Hmmm. Another interesting YAML edge case. The authors proposal that YAML have “unsafe” loading be an explicit case seems like a good suggestion.

                  1. 4

                    The authors proposal that YAML have “unsafe” loading be an explicit case seems like a good suggestion.

                    Better several decades late than never.

                  1. 2

                    I mean this with no snark - But perhaps the author shouldn’t be using Ruby? The (very) dynamic type system is it’s biggest strength and weakness. And one of those weaknesses is constantly wondering what kind of object you’re dealing with.

                    Plus, this might be possible in your own confines, but Ruby is also about the gems. The Law of Demeter is fine, but equally I don’t see it applied in libraries - where idiomatic Ruby* has a lot of “magic”. Expressiveness is favored over correctness and encapsulation - dynamic programming, operator overloading, monkey-patching, DSL-for-everything.

                    *I’d be hard pressed to nail it down to be honest.

                    1. 4

                      I think the philosophy tag applies here.

                      Nice writeup. We’re doomed. Hope that even though we form part of the AI’s kernel, they won’t repeat humanity’s mistakes.

                      1. 1

                        We’ll definitely be in the kernel. Hopefully the better parts…

                      1. 1

                        Interesting idea, poorly constructed argument. The core insight that the self is decentered, that a large part of our psyche is located outside of our brain or “mind” and impacted by gut flora etc is correct, this was one of Freud’s ideas. I suggest the author read up on Freud, psychoanalysis, and cognitive science, in particular “extended cognition”.

                        1. 2

                          Definitely poorly constructed. I have a tag of “I need an editor”. Was more to scratch an curious thought than extend any particular field (hence science-fiction rather than science).

                          Another thread I pulled was using “A Deepness in the Sky” as a basis - this is much more pure as it’s civilization on a vast time/space scale (one particular core thread is this -scarily- necessitates a collapse-and-rebuild cycle). I think I mostly picked AI because it’s a more approachable reality right now.

                          1. 2

                            Oh I see, as exploratory writing it makes much more sense. I guess I read it wrong. Anyway, I still recommend reading up on those things, it’ll push your thinking on this even further :)