3 ms·

So much this. Woe to you if you got to ipo on a pile of garbage. But ipo you say! Good luck scaling, adopting dev ops best practices, and keeping any sort of sl

So much this. Woe to you if you got to ipo on a pile of garbage. But ipo you say! Good luck scaling, adopting dev ops best practices, and keeping any sort of sla’s on that. And reducing cost or on boarding new hires? Pain is in your future.

horsawlarway 5y ago
You can get to an IPO on a pile of garbage, or you can go out of business. I think the quote that comes to mind for me (as someone who's been with 2 startups now that have grown from less than 20 employees to more than 300) is this: One man's trash is another man's treasure. "Good" code written with the constraints of a tiny company won't be "good" code later anyways - the requirements will shift, the company goals will change, focus will change away from some features towards other features, abstraction levels will be different, the quality of your engineers will be different. Trying to bake in assumptions about what "good" will be 5 years down the line is literally pain for no reason, and I promise you it will be wrong anyways. Trying to act like the company from 5 years down the line is a guaranteed way to go out of business in the mean time.
- morbia 5y ago
  To some degree you are right, but the sign of good quality code with low technical debt is the ability to change requirements quickly, not necessarily consider future requirements. In my opinion, investing early on in CI/CD pays so much more than thinking about code quality, correct abstractions and future requirements. If I have a fast deployment strategy with automated testing I can trust, accommodating new features is a breeze regardless of the underlying code quality. Of course though it's all a balancing act. I could spend a year building a solution using sophisticated tools like spinnaker, only to completely miss the market at a startup. Still, if there is a tradeoff to be made between code quality and CI/CD, I'd always side with CI/CD.
  - slt2021 5y ago
    I see ci/cd mentioned every time there is a talk about tech debt, but I dont buy it. The code mess is usually in the code itself, the abstractions being used, the db schema, and etc - how does ci/cd help tackle this kind of tech debt?
    - rileymat2 5y ago
      It does not, but I have taken on projects that took weeks to build because the one developer who wrote it only built it on his personal computer with a nest of undocumented dependencies and unknown versions, years old. So before fixing other things you need to be able to build it.
- mavelikara 5y ago
  My opinion is the same as yours, but with one modification - I will replace "code" with "architecture". Even when doing the simplest possible thing that'd work, one can write code in such a way that will create a disaster. That is the difference between a codebase that can evolve after PMF, and one that will take the company down.

horsawlarway 5y ago

You can get to an IPO on a pile of garbage, or you can go out of business. I think the quote that comes to mind for me (as someone who's been with 2 startups now that have grown from less than 20 employees to more than 300) is this: One man's trash is another man's treasure. "Good" code written with the constraints of a tiny company won't be "good" code later anyways - the requirements will shift, the company goals will change, focus will change away from some features towards other features, abstraction levels will be different, the quality of your engineers will be different. Trying to bake in assumptions about what "good" will be 5 years down the line is literally pain for no reason, and I promise you it will be wrong anyways. Trying to act like the company from 5 years down the line is a guaranteed way to go out of business in the mean time.

morbia 5y ago
To some degree you are right, but the sign of good quality code with low technical debt is the ability to change requirements quickly, not necessarily consider future requirements. In my opinion, investing early on in CI/CD pays so much more than thinking about code quality, correct abstractions and future requirements. If I have a fast deployment strategy with automated testing I can trust, accommodating new features is a breeze regardless of the underlying code quality. Of course though it's all a balancing act. I could spend a year building a solution using sophisticated tools like spinnaker, only to completely miss the market at a startup. Still, if there is a tradeoff to be made between code quality and CI/CD, I'd always side with CI/CD.
- slt2021 5y ago
  I see ci/cd mentioned every time there is a talk about tech debt, but I dont buy it. The code mess is usually in the code itself, the abstractions being used, the db schema, and etc - how does ci/cd help tackle this kind of tech debt?
  - rileymat2 5y ago
    It does not, but I have taken on projects that took weeks to build because the one developer who wrote it only built it on his personal computer with a nest of undocumented dependencies and unknown versions, years old. So before fixing other things you need to be able to build it.
mavelikara 5y ago
My opinion is the same as yours, but with one modification - I will replace "code" with "architecture". Even when doing the simplest possible thing that'd work, one can write code in such a way that will create a disaster. That is the difference between a codebase that can evolve after PMF, and one that will take the company down.