10 ms·

After nearly two decades in early stage startups I couldn’t agree more. Looking back, I know we often built too much too soon, and had too much confidence that

• kirse 4y ago
  too much confidence that we were building the right thing SW is weird in that way, we can basically build houses that nobody wants to live in. Thing is you probably were building the right thing, structurally speaking. My rule over time has become "structure follows complexity" i.e. Anticipate complexity where possible but don't apply the engineering structure until the complexity really exists. If you built an MVP house, don't add the second bathroom until you've got customers complaining about deadlocks on the first. It's tough because that basically runs counter to the Spirit of an Engineer, which is just to imagine the grandest well-thought-out + organized thing and march toward creating it. The bonus of having two decades+ in building SW though is you start to see the patterns and realize that the same fundamental needs drive everything, so the intersection of building something great with customer needs becomes less of a mystery and more of a "how fast can we juice this thing". At that point I think scalability prep is like compound interest.
  • hinkley 4y ago
    There’s a ninety ten rule with structure that can be hard to communicate in code reviews. There’s a subtle difference between not adding unnecessary structure and writing code that is antagonistic to it being added later. Opening a PR where someone added a feature or fixed a bug exactly where I would have done so is one of the best feelings. Especially when they’re changing my code. Either they’re a very good coworker or I’ve laid the groundwork well. Either of these are good news. Very recently I’ve come to think of my architecture style as Jazz. Like the old trope about listening to the notes he isn’t playing. But also the improvisational nature and the flexibility to adapt to new information.
    • doctor_eval 4y ago
      > There’s a subtle difference between not adding unnecessary structure and writing code that is antagonistic to it being added later This is such a wonderfully concise way of describing something that I try to teach people. I have come to use the phrase "no regrets". Leave things out, but do it in a way that you won't regret it, if you need to add it later. Another phrase that I read somewhere else was, "Weeks of programming can save you hours of planning" (pretty sure I read it on HN, and I wish I had kept the link). The point being that when you decide to leave something out, or when you decide to intentionally do a half-assed job of something, you should still think about how someone in the future would go about efficiently fixing it. If you do it right, there's missing functionality, but little or no technical debt. If you do it wrong, you miss out on functionality and also take on technical debt. And I think that's the subtlety that you speak of.
      • hinkley 4y ago
        Most people who push for early design understand that they have more control of the project at the beginning, before deadlines accelerate, before a bunch of bad hires and competing priorities. And they are definitely speaking from a place of regrets. This hurt so much last time I vowed never again. There’s a list of things I won’t try to add on later. It’s smaller than it used to be, but the shiv I brandish at you for suggesting we cut those corners is also much scarier.
        • doctor_eval 4y ago
          Yes, 100%. Some things you can cut corners and save time. Some things, when you cut the corners off you also cut your fingers off. We have all promised that we will “fix it later”. But whatever we do now is what’s done. Fixing it later is a promise whose resolution is often not in our control.
          • hinkley 4y ago
            I suspect this dynamic is a big part of why Joel Spolsky jokes about transforming from a technical leader into an amateur psychologist. We are all lying to ourselves first and to others second. Or as Feynman said, the trick is not to fool yourself, and you’re the easiest person to fool. Or a personal favorite, unattributed: I know the guy who made this plan [me] and he’s full of shit.
  • bcrosby95 4y ago
    I call it "keeping an escape hatch". The potential need to scale and add features will inform my design decisions, but they will not direct them.
    • pfarrell 4y ago
      "keeping an escape hatch". I like that. A former colleague said something similar that also stuck with me. Good software architecture allows you to delay decisions.
    • damethos 4y ago
      I use "always keep an out", which is taken from poker terminology, but I like yours as well.
  • alexvoda 4y ago
    China proves that building cities worth of actual houses that nobody wants to live in is a thing.
    • andirk 4y ago
      We talking Dandong, city at the border of China and North Korea? They built everything including a giant bridge, high-rise apartments, shopping centers, parks, and a ferris wheel. But there's no people and it's been ~10 years now. It is, however, still fully maintained. [0] [0] https://www.globaltimes.cn/content/974210.shtml https://www.globaltimes.cn/content/974210.shtml
      • minusf 4y ago
        wikipedia says 2M people live there: https://en.wikipedia.org/wiki/Dandong https://en.wikipedia.org/wiki/Dandong
        • andirk 4y ago
          Yup. Literally first sentence of my citation "Dandong New City, a district of Dandong which was built from scratch to be a China-North Korean trade hub, now stands mostly empty." [0] [0] https://www.globaltimes.cn/content/974210.shtml https://www.globaltimes.cn/content/974210.shtml
    • unity1001 4y ago
      A large number of those cities are filled, and various of them are 'tier 2' cities now. That means 10 million people.
      • tayo42 4y ago
        Wikipedia has only 7 Chinese cities listed with a population over 10 million
      • onlypositive 4y ago
        A large number of them aren't and they're crumbling apart after only a couple of years being built. https://youtu.be/XopSDJq6w8E https://youtu.be/XopSDJq6w8E
  • Frost1x 4y ago
    >It's tough because that basically runs counter to the Spirit of an Engineer, which is just to imagine the grandest well-thought-out + organized thing and march toward creating it. I'm not sure if Spirit of an Engineer is a book, essay, or some prior set of principles I'm unaware of but if it's not (and even if it is), I tend to disagree here. The spirit of of an engineer, in my opinion, is to solve problems and problems for people--that's what I and most engineers I've spoken with have been drawn to (ignoring those purely seeking a high paying profession here since were talking about "spirit"). When I was youthful I sought out technical complexity and grandiose solutions (I admittedly still admire it when it's done correctly). None the less, to me, most of it is wasteful and at the end of the day I want to build the most useful solution for people to make their lives easier. Some problems require high complexity and glass cathedrals in terms of technical solutions, most really don't, at least most of the problems I've been exposed to.
    • btilly 4y ago
      Actual engineers generally do try to solve problems for people. But the engineers understanding of the people that they are solving it for is generally rather flawed. And therefore their solutions frequently are difficult for the intended users for reasons that the engineer can't see. And yes, engineers really do err on the side of designing for future problems and future users that often will never exist. This effect is worst on a rewrite of a system - look up the "second system effect". We tend to only truly get pragmatic tradeoffs the third and later times.
    • jgoodhcg 4y ago
      Maybe “spirit of an engineer” could be better phrased as “visionary mindset”. Lots of engineers I’ve worked with imagine potential problems and treat them as requirements to solve even though the problem may never actually materialize.
      • andirk 4y ago
        Figuring out which problems to solve before they happen and ignoring the ones that probably won't happen is the cosmic dance of software development. The Serenity Prayer states "... accept the things I cannot change, courage to change the things I can, and wisdom to know the difference." Except change "cannot"/"can" to "don't need to at least not yet"/"need to now because it's about to be an issue!". Make a bare bones version and see if it sticks, and go from there. Both the Progressive Enhancement philosophy and the Lean Startup methodology demand the minimal before building further. Ex: Will anyone click this survey link? Who knows but you'll learn real quick if you offer them $50. If they still don't, then it probably ain't gonna get clicked ever. If they do, then you found at least _something_ viable.
  • deleted 4y ago
    [deleted]
  • yieldcrv 4y ago
    you really couldn't write software? I’d vote for SWE if we are taking up acronym namespace
    • kmoser 4y ago
      Writing "SW" instead of "software" is just another example of premature optimization.
  • chii 4y ago
    > Spirit of an Engineer, which is just to imagine the grandest well-thought-out + organized thing and march toward creating it. i think that's just delusions of grandeur. Not everybody would be (or should be) building the sistine chapel.
  • lozzo 4y ago
    Yours is an incredibly good comment. The comparison software/architecture is something that I have encountered here and there over the years, but you brought it to a new level. "don't add a second bathroom until you ve got customers complaing about deadlocks on the first". Beautiful. Thanks
• dhbradshaw 4y ago
  I think this is the right approach. There is however a pitfall that this approach seems to lead to unless you actively prevent it. Roughly the process is 1. You hire someone to take care of things manually. 2. As you grow, your devs are worrying about other things and so instead of automating you hire more and more people to handle the toil that should have been automated along the way. 3. Because these jobs are handled by one group of people and developers are working on customer facing features, the communication and prioritization necessary to fix the issues rarely come up.
• avip 4y ago
  In other words, founders keep insisting on not reading the lean startup, or ignoring all the advice given there. Ignoring history is a guaranteed path towards repeating it.
• rr808 4y ago
  Steve Blank has talked about this for decades. A startup is about validating you have a product that customers want. You want to connect with customers and prove you have a market before scaling. https://steveblank.com/tag/customer-validation/ https://steveblank.com/tag/customer-validation/
• davnicwil 4y ago
  I think this kind of concierge / person behind the curtain approach only works for a certain type of business though, usually services where aspects of the service pipeline can either be automated or not. For purer technology / product businesses, how do you do this, fundamentally? How would Google have manually mocked up their early product? How would Facebook? Github? Tesla for that matter? Sometimes you really do just unavoidably have to build the product out before testing the market, and if it doesn't work, just accept the sunk cost and throw it away - and sometimes fail completely as a result. I don't see this as a fundamentally solvable inefficiency, just part of how tech product startups work, and the very tradeoff that must be made to allow for innovation to happen.
  • fragmede 4y ago
    > how do you do this, fundamentally? How would there are still smaller pieces you can MVP to a smaller audience before launching it to the world. > Google have manually mocked up their early product? How would Crawl an intentional community (remember webrings?) or other small directed subset of the web and see if you're able to get better search results using terms you know exist in the corpus, rather than all of the Internet. > Facebook? They had Myspace as an example so the idea wasn't exactly unproven. > Github? Kernel developers were already using the software, successfully, all (for large values of "all") they did was bring it to a wider market with a better UI. > Tesla for that matter? People don't get this, but Tesla's biggest achievement to date, isn't the cars themselves, but the factory that they're built in. There's no way to MVP an entire factory, but building a car in a bespoke, pre-assembly fashion is totally possible and totally doesn't scale. If you're asking if electric cars were known to work, the first one came out in 1832. If you're asking about product-market fit, they keep selling cars they haven't made yet, just to gauge demand. Aka where's my Cybertruck!?
    • itake 4y ago
      Most startups have a red-ocean indicator in the space to point at when telling people about their problem. Most startups fail.
      • 4y ago
• adrr 4y ago
  It really depends on the situation. No one at a successful startup says, we spent too much time on scalability in the beginning. They probably say the opposite. I worked at one company that we couldn’t rack servers fast enough to keep up with our growth. Our competitor who was the market leader had to turn off the ability for new customers to signup to prevent their site from crashing under load. We ended up surpassing them. Getting a million customers isn’t that challenging and really a function of money. With $50 CPA, you just need $50m. 1m customers will take down most sites unless you do some optimizations.
  • klabb3 4y ago
    I think you’re both right, even if I’d guesstimate the situation you encountered is very, very rare. You should make architectural choices that CAN be scaled within reason, on demand and ideally incrementally. That doesn’t mean you need to build your app on Kubernetes and automate welcome emails, surveys, metrics, A/B testing etc. But you probably shouldn’t build on top of fundamentally non-scalable systems either. This is provided you’re in an environment that can reasonably scale to 1M users or whatever, which isn’t true for all domains. Say B2B where that last B is only 10000 people world wide.
    • what-the-grump 4y ago
      It’s difficult to explain to people what you said without the experience of living in the failures of early optimization. K8s from day one, a-b testing, programmatic quality control without any paying clients on the product, scrum master and a PM and a product owner for 5 devs! Whole thing feel like a Ponzi scheme to keep overseas staff employed, perpetrated by the overseas development shop. Unless you built something absolutely atrocious, scaling it vs getting it ‘right’ or ‘right enough’, is trivial. You couldn’t sign up to Facebook if you weren’t a college student. Chatgpt overloads daily so what? When your app becomes necessary to enough people, bring in your k8s evangelists and shove into x cloud provider. But by god it doesn’t take 30 people to write a marketable mvp.
      • klabb3 4y ago
• roncesvalles 4y ago
  This seems like a big reason why taking on investors too early can be harmful. You can't be sitting on runway money and taking baby steps with it, even though sometimes that's the right thing to do.
  • deleted 4y ago
    [deleted]
• osigurdson 4y ago
  Is it possible to generate enough excitement with just a Google sheet however? I suppose if it is B2B it would be fine.
  • ant6n 4y ago
    Well don't tell the public there's a Turk under that AI chess board.
    • osigurdson 4y ago
      What type of business is this? It would be hilarious to have a human reading through http requests and writing out responses!
      • constantly 4y ago
        They seem to be discussing the more complex, business- and customer-driven aspects of technology, not the simple process of building a CRUD application. DoNotPay.com is one of these examples. It's a straightforward CRUD software where one enters parameters to establish a contract; however, despite claims to the contrary, a human being actually creates the contract form and sends it back 24 to 72 hours later. The entire enterprise embodies the idea of a Mechanical Turk.
• maerF0x0 4y ago
  > with just the minimum amount of tech. as an engineer this part I entirely agree with. Far too often CEO driven development leads to pivoting 1Month into 9 month projects, 9 months in a row. such that you have nothing deployed when you at least could have had 1 thing, but instead you have none. This can be solved as much by discipline to stay on track as by choosing to reduce scope to 1 month ideas only.
• amelius 4y ago
  Except it doesn't work when your project ends up on HN's front page and your server gets hugged.
  • jdlshore 4y ago
    The HN effect is overrated. I had two articles on the front page at the same time and never exceeded 1000 requests per minute. And very very few of those visits turn into repeat users. Edit: (The load was easily handled by a single Heroku dyno. I turned it up to two dynos overnight, just in case, but it turned out to be unnecessary.)
  • KyeRussell 4y ago
    Not being able to deal with low quality traffic spikes is one of those things that engineers see as a failure, but aren’t necessarily so from a business perspective when compared with the potential cost of a scalable infrastructure. Not that all spikes are low quality, or even that one on HN ones are. I reckon for some products they are.
• mushbino 4y ago
  Hire an experienced (0-1) Product Designer and have them work out the features, design, system, interaction flow, and research. Test and validate you have the right thing before you start building. This can be done well in 6 weeks and it'll save years and years of debt.
  • pstorm 4y ago
    Where do you find someone like this?
    • chefandy 4y ago
      Anywhere you'd find any other employee. Product designers aren't rare, it's just that immature development organizations usually use designers wrong. Bringing designers in at the end to add polish to the user's experience nearly guarantees they'll be polishing a turd. A big part of a designers value is figuring out what problem users need to solve with your software and what tools they need to do so.
      • mushbino 4y ago
        100% on the money
• alexbrower 4y ago
  I do at least 2 of these calls per day. Interacting with end users is the only way to maintain PMF. IMO anyone too big, cool, or fast-growing… sadly mistaken.
• rajup 4y ago
  Hard to get funding with such a pitch.