4 ms·

This. As I always say, "If you are building a startup, over-engineering is a far bigger sin than creating technical debt."

andbberger 8y ago
That's just a cop out! Such a tired meme!
- angersock 8y ago
  It's true though. What's your counterargument? Tired memes can be tired because they're true.
  - hobofan 8y ago
    If you want your startup to run for more than a year (= roughly the time the effects of technical debt start to kick in significantly in my experience), you need to find a good way how to handle technical debt, and keep it in check. I have seen my share of startups where a platform plagued with technical debt was the main limitation for growth, which is a very avoidable situation.
    - JumpCrisscross 8y ago
      > If you want your startup to run for more than a year I've never seen a start-up fail on account of technical debt. Re-engineering is expensive, but it means you have something worth re-engineering. I've seen lots of start-ups fail because money that should have been spent attracting and retaining users got burned on an elaborate engineering process.
      - andbberger 8y ago
        Ok but like middle ground exists here. There is a huge difference between thinking carefully about what you need to do right and planning what bits are going to end up as technical debt, and how you can fix it later - and what actually ends up happening in my experience where everything is shit because we're too busy being a s t a r t u p to practice engineering.
        JumpCrisscross 8y ago
        > middle ground exists here The point is the middle ground exists closer to shitshow than well-oiled shop. If the CEO doesn't understand this, they won't be CEO for long.
      - jiaweihli 8y ago
        > I've never seen a start-up fail on account of technical debt. That's because noone ever says "XYZ startup failed because their code quality wasn't good enough." It's usually something closer to "Their customers didn't renew contracts, they had to slash headcount, and went into a death spiral from there." If you press for details, the deeper reason might be "they couldn't turn around features fast enough" or "the app was slow or their servers went down too much" which is a symptom of too much technical debt (either directly, or because the better engineers on the team choose to leave as a consequence of the technical debt). I agree that early startups don't fail because of technical debt, but I'd bet that many mid-size startups do fail because of it.
        icedchai 8y ago
        I've been in startups since the late 90's. Not once have I seen a startup fail due to technical issues. Several of these made it to the double digit million raised, 100's of employee phase. Failure was always related to the wrong product being built or a bad business model (poor product/market fit, pricing is screwed up, some sales, but not enough to cover cost, no plan for marketing, etc.) Poor code quality is rarely perceivable by customers, except in the most extreme cases.
ryanSrich 8y ago
But having CI, proper logging, and code review isn’t over engineering. The time, effort and bugs saved by spending 1-2 days putting these policies and procedures in place is valuable early on. Of course, each of those pieces is at risk of becoming over engineered. But hopefully the team has a leader that knows when to move forward and when to pull back.
- mcv 8y ago
  Particularly CI. If you want to be able to release fast and often, having that automated is going to save you a lot of time. And CI doesn't immediately have to include everything you'll eventually want; just having automated build and deploy will make your life a lot easier. Add some automated testing as soon as you can afford to (which hopefully is right away, because it's not that hard to set up), and you're ready to move.
kybernetikos 8y ago
And in many places they go hand in hand - some pieces of code will be massively over-engineered and genericised for a future that will never come, while other, important (but possibly less interesting) pieces will be peppered with // TODO and // THINK ABOUT THIS LATER.
t0mbstone 8y ago
Setting up CI is basically as simple as adding a small .yml config file to your git repo (if you are using a service like Travis or Circle CI) and clicking a couple of buttons to give the tool access to your github repo.
- rjvs 8y ago
  If you are writing a web app maybe, if you’re writing a VR app, it’s definitely not that easy.
  - retiredcoder 8y ago
    True to that. Software engineering isn’t just web apps.
flukus 8y ago
Isn't over-engineering a type of technical debt? At the very least both can exist simultaneously.
pandler 8y ago
Unfortunately I’ve met some people that take that mentality to a macho extreme in the form of “if you want to be STARTUP, you should actively avoid doing anything that resembles forethought.”

andbberger 8y ago

That's just a cop out! Such a tired meme!

angersock 8y ago
It's true though. What's your counterargument? Tired memes can be tired because they're true.
- hobofan 8y ago
  If you want your startup to run for more than a year (= roughly the time the effects of technical debt start to kick in significantly in my experience), you need to find a good way how to handle technical debt, and keep it in check. I have seen my share of startups where a platform plagued with technical debt was the main limitation for growth, which is a very avoidable situation.
  - JumpCrisscross 8y ago
    > If you want your startup to run for more than a year I've never seen a start-up fail on account of technical debt. Re-engineering is expensive, but it means you have something worth re-engineering. I've seen lots of start-ups fail because money that should have been spent attracting and retaining users got burned on an elaborate engineering process.
    - andbberger 8y ago
      Ok but like middle ground exists here. There is a huge difference between thinking carefully about what you need to do right and planning what bits are going to end up as technical debt, and how you can fix it later - and what actually ends up happening in my experience where everything is shit because we're too busy being a s t a r t u p to practice engineering.
      - JumpCrisscross 8y ago
        > middle ground exists here The point is the middle ground exists closer to shitshow than well-oiled shop. If the CEO doesn't understand this, they won't be CEO for long.
    - jiaweihli 8y ago
      > I've never seen a start-up fail on account of technical debt. That's because noone ever says "XYZ startup failed because their code quality wasn't good enough." It's usually something closer to "Their customers didn't renew contracts, they had to slash headcount, and went into a death spiral from there." If you press for details, the deeper reason might be "they couldn't turn around features fast enough" or "the app was slow or their servers went down too much" which is a symptom of too much technical debt (either directly, or because the better engineers on the team choose to leave as a consequence of the technical debt). I agree that early startups don't fail because of technical debt, but I'd bet that many mid-size startups do fail because of it.
      - icedchai 8y ago
        I've been in startups since the late 90's. Not once have I seen a startup fail due to technical issues. Several of these made it to the double digit million raised, 100's of employee phase. Failure was always related to the wrong product being built or a bad business model (poor product/market fit, pricing is screwed up, some sales, but not enough to cover cost, no plan for marketing, etc.) Poor code quality is rarely perceivable by customers, except in the most extreme cases.

ryanSrich 8y ago

But having CI, proper logging, and code review isn’t over engineering. The time, effort and bugs saved by spending 1-2 days putting these policies and procedures in place is valuable early on. Of course, each of those pieces is at risk of becoming over engineered. But hopefully the team has a leader that knows when to move forward and when to pull back.

mcv 8y ago
Particularly CI. If you want to be able to release fast and often, having that automated is going to save you a lot of time. And CI doesn't immediately have to include everything you'll eventually want; just having automated build and deploy will make your life a lot easier. Add some automated testing as soon as you can afford to (which hopefully is right away, because it's not that hard to set up), and you're ready to move.

kybernetikos 8y ago

And in many places they go hand in hand - some pieces of code will be massively over-engineered and genericised for a future that will never come, while other, important (but possibly less interesting) pieces will be peppered with // TODO and // THINK ABOUT THIS LATER.

t0mbstone 8y ago

Setting up CI is basically as simple as adding a small .yml config file to your git repo (if you are using a service like Travis or Circle CI) and clicking a couple of buttons to give the tool access to your github repo.

rjvs 8y ago
If you are writing a web app maybe, if you’re writing a VR app, it’s definitely not that easy.
- retiredcoder 8y ago
  True to that. Software engineering isn’t just web apps.

flukus 8y ago

Isn't over-engineering a type of technical debt? At the very least both can exist simultaneously.

pandler 8y ago

Unfortunately I’ve met some people that take that mentality to a macho extreme in the form of “if you want to be STARTUP, you should actively avoid doing anything that resembles forethought.”