4 ms·

Startup founders should be explicitly telling their developers to not write tests, not use CI/CD, not use feature branches. All that stuff can come after you h

Startup founders should be explicitly telling their developers to not write tests, not use CI/CD, not use feature branches. All that stuff can come after you have proven your software makes money / users want to use it. Just get the damn thing written in the quickest, most crappy way necessary for speed. The code doesn't need to be organised well. It doesn't need to be documented. The only thing that matters is to do your best to avoid security holes. No tests. Stop testing, apart from manual runthroughs that the CEO can do in between trying to raise funding. My eyes roll when I hear of startups creating "good processes" for development at any level, let alone CI/CD and tests.

pier25 4y ago
I totally agree. Stop thinking like a developer, think like a business owner. Build the MVP so that it's good enough to start solving whatever it is you're solving and get your first customers. If you can't get customers, what's the point of having a sophisticated codebase with tests, etc?
- presentation 4y ago
  Not even solving, just making it sellable.
- andrewstuart 4y ago
  >> If you can't get customers, what's the point of having a sophisticated codebase with tests, etc? And in fact every minute spent on writing and running tests (and there's always ALOT) and CI/CD is wasted, wastes money and time, leading to longer development time until the software can be put in front of users. Therefore CI/CD and tests and all their associated processes are a red flag and increases the likelihood a startup will fail to bring its software to market. Developers who have always worked in well organised environments have really deep rooted trouble getting their head around this way of thinking. If you say to an experienced developer "no tests! no CI/CD!", it's likely they will immediately decide you are an unprofessional hack.
  - ryandrake 4y ago
    I met a founder with this mentality--but the problem was, the company was no longer a start-up, he had dozens of products, many (unhappy) customers, and zero development process that wasn't "writing code". He still believed every minute you spent on writing something that was not directly shipping to customers was his money being wasted. I had to argue with him to even get source control set up (he didn't agree, and I just did it in secret at night anyway). CI/CD?? Fuggetaboutit. Releases were pulled directly off the PC of any engineer who managed to get the software built without errors that day. Yes, they were usually debug builds with symbols, and never reproducible. Needless to say, it was a clown show.
    - pier25 4y ago
      Yeah the issue is adapting to what the business needs. Once you have customers the mindset should be totally different.
- jiggawatts 4y ago
  I use Maslow’s Hierarchy it Needs when discussing stuff like this in my consulting gig. E.g.: it doesn’t matter what fancy SIEM tool you’re using if you never patch anything and the root password is “password”. “But the vendor assured us that it would solve our security issues!” is the inevitable reply.
agrippanux 4y ago
I hear ya; you're not off on most of this. However if you're building a web service, Vercel (and its kin) make CI/CD ridiculously easy. Easy as in like 5 minutes easy, and it's worth the 5 minutes for the all the benefits.
- presentation 4y ago
  Yeah and most web framework init scripts even fully set up a testing framework too.
- andrewstuart 4y ago
  >> Easy as in like 5 minutes easy, and it's worth the 5 minutes for the all the benefits. The sum total of time spent on CI/CD and tests is not the time it takes to get it started, it's the time spent executing the tests/CI/CD into the future, thinking about the tests/CI/CD, problem solving the tests/CI/CD. All these things require ongoing time which takes time away from developing the application.
  - HWR_14 4y ago
    Thinking about the tests may be an ongoing cost, but the whole point of CI/CD is that I never have to think about certain things again. That's also the idea behind the tests, but there is admittedly more work keeping the tests up to date than the CI/CD pipeline.
wpietri 4y ago
You stopped telling the story at the most interesting part. At my last startup, I wrote totally throwaway code on all our initial prototypes. Once we had something that looked like it would hit product-market fit, I hired a team, we threw away the shitty codebase and started fresh. If you don't throw it all away after making the kind of mess you describe, then you are going into the company's most crucial time with a boat anchor around your ankle and the water level rising. I'm very glad we did, as starting fresh with tests, CI/CD, and other quality practices let us be extremely responsive to my cofounder's needs and the things we learned from every release.
- andrewstuart 4y ago
  Getting the job done is all that matters. This is why an experienced developer is sometimes the wrong person for the job to build a startups first version, unless they are able to fully embrace the mindset of prioritising speed over everything. Beware of experienced developers who get the job of writing a startups first code and who start talking about tests/CI/CD/feature branches and all that stuff. Avoid security holes and take backups, that's all that matters and anything else should be actively avoided.
  - wpietri 4y ago
    Again, you seem to be stopping the story at the wrong point. The initial job is to find out whether the project is worth investing in. 9 out of 10 startups fail, they say; if you're in one of the 9, you need to know that ASAP. If you can tell that with throwaway code, great! You've saved a shit-ton of money. As an example, I did a startup circa 2010. We raised money on an idea that VCs were very excited about. So much so that we found out later that other VCs had invested in similar notions. We spent a few months building disposable prototypes to test the value prop. It turned out that users hated the idea no matter what we tried. So we killed it after spending maybe $100k and did something else. Job done! But the other companies persevered, building full apps, and each burned millions before they realized there was no future in it. So in that case, yes, you don't want to invest a lot. But a few ideas later we had something that looked to have real product market fit. At that point, we threw away the code and started fresh with solid tests, CD, and other quality investments. Why? Because the job we were trying to do had changed. It had gone from hypothesis testing to actually serving users and building a real product. If you want to get that job done well, you can't afford to have a garbage code base.
hn_throwaway_99 4y ago
> not use CI/CD That is ludicrously bad advice. Setting up a straightforward CI/CD pipeline can take a couple hours and it instantly provides huge productivity benefits. I worked for a startup that didn't have an automated deploy pipeline and didn't have any tests. It was a complete shit show from day 1, and I will never work for that chaotic of an environment again. I am certainly not for over-engineering early in a company's lifecycle, but there are simple, "table stakes" things like use of SCM, automated builds and CI/CD pipeline. If I don't see those I assume your engineering team doesn't know how to build software fast.
- andrewstuart 4y ago
  The number of hours I have seen developers spend on things related to CI/CD is vast. Kill CI/CD with fire for the sake of speed. "Craptacular development mindset" is needed.
  - selcuka 4y ago
    > The number of hours I have seen developers spend on things related to CI/CD is vast. Sure, same as everything else that is overengineered. A simple, no-frills GitHub Action (or equivalent) should not take longer than a few hours to implement. If you need more time than that, it means that you have an overly complicated deployment process, which is a time sink when done manually anyway.
datavirtue 4y ago
Hmmm....our startup deals with people's money. I fuck up, they can't buy gas. I prefer tests over working code.
- andrewstuart 4y ago
  That's a requirement of your software. Your software should meet the minimums standards required by your target user. That's the "viable" part of Minimum Viable Product. In a similar vein, you cannot release a new antivirus product that does not detect viruses, or security product that does not make things more secure. Software development has (or should have) defined priorities - and if accurate financial transaction processing is a base requirement then that's the minimum viable product you need to deliver. And if it takes tests to do that, then that's what you need.
wefarrell 4y ago
Yeah devs also don't need to use VCS, and instead of hosting it on servers just host it from a laptop using ngrok. Better yet just get rid of the code entirely and manually perform whatever tasks your users need.
kareemsabri 4y ago
CI/CD takes like 3 hours to set up and saves you hundreds of hours in deployment time. It delivers new features to your customers faster, lets you ship more frequently because you know you can roll forward quickly or revert when you mess up. Any startup founder who tried to tell their devs not to bother with CI/CD (if it's a real product, not just a prototype or proof of concept) probably doesn't know what they're doing. Being a startup doesn't mean your tech has to be garbage. So many miserable devs hoping that "after series A" they'll get to refactor that spaghetti code mess (they won't) and seeing their velocity slow to a crawl because they can't make a change without worrying the whole thing is gonna break.
robocat 4y ago
1. you are stating an opinion as fact, which is rude. Other people have facts that disagree with yours. 2. you are wildly unclear about your preconditions. I am pretty sure you are talking about the initial stages developing an MVP for a startup. Other comments are probably referring to the startup growth period following the MVP.[1] 3. You might be right in some circumstances. But your assumption elsewhere in comments that CI causes over-engineering is incorrect: any team that has an over-engineering problem will generally be in trouble, which is not caused by CI. 4. You are replying to many comments dismissively, almost attacking with your “facts”. If your argument is strong, others will answer for you. “ Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.” — https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html [1] I’m using this definition for startup http://www.paulgraham.com/growth.html http://www.paulgraham.com/growth.html — personally I dislike PG’s definition of a startup (paraphrased: designed for fast growth). Should a business that is trying-but-failing-to-grow not be a startup? A business designed for slow growth but large market is not a startup? PG gives Google as an example of a startup, yet that contradicts his own essay: didn’t Google have a lot of luck, and it isn’t obvious to me that Google was designed for growth, more that the opportunity knocked and Google jumped on that opportunity, successfully. Some of PG’s definition feels tautological; 20/20 hindsight. Edited: made politer.
- andrewstuart 4y ago
  >> 1. you are stating an opinion as fact. Other people have facts that disagree with yours. Agreed. I have made an error there. >> 4. You are replying to many comments dismissively, almost attacking with your “facts”. If your argument is strong, others will answer for you. “ Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.” — https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html Agreed. I have made an error there. I should choose a better tone. I do work hard to get the tone right but not successful today obviously. Apologies if this has offended anyone. I usually delete things that I feel are too negative, adversarial, preachy or otherwise not the right tone. >> 2. you are wildly unclear about your preconditions. I am pretty sure you are talking about the initial stages developing an MVP for a startup. Other comments are probably referring to the startup growth period following the MVP.[1] The comments I make are about a company pre product/market fit, doing the first build of its software before opening the doors to customers. I do agree that the startup period continues beyond this perhaps for a number of years, at which time development priorities might change. >> [1] I’m using this definition for startup http://www.paulgraham.com/growth.html http://www.paulgraham.com/growth.html For reference, in the link PG says "A startup is a company designed to grow fast.". This seems overly narrow because it seems self evident that there is lots of startups that have different objectives to fast growth. My definition for a startup is more like Steve Blank's: “A startup is a temporary organization designed to search for a repeatable and scalable business model.”
eagsalazar2 4y ago
Chaos has a cost too. You need to weigh that against the cost of testing. And both chaos and testing cost exist on a very broad continuum. For very trivial prototypes, spending even a few hours on tests obviously outweighs any benefits. And 100% unit testing coverage never pays off even on larger projects. However a few hours of setting up CI/CD with linting, type checking, required reviews, automated deployments, and yes some sanity checking integration tests, can provide massive velocity benefits that pay back the investment in a few days and are pure velocity windfall thereafter. I think you (a) have been burned (and I'm not denying testing can be a waste of time) and (b) not being a dev yourself you don't fully understand that this isn't a black and white issue or that you are actually paying a massive velocity cost by doing zero testing. Your POV is akin to advising people to not drink water on a hot, strenuous hike because "every time you lift your arm to drink, you are wasting energy that could go to your legs". Uh yeah, in both cases it's a little more complicated than that. Definitely don't waste an hour making a gourmet meal (and yes I get sometimes devs do this), but there are a spectrum of options and there is a sweet spot. How about "drink some gatorade and eat a power bar without slowing down"? Getting that balance right isn't trivial but it is possible and the payoff is huge. Which goes to the other point you made about not hiring expert devs, man, you've been hiring the wrong experts if you think fresh, unsupervised bootcampers are a better choice at any stage other than "can you make me a framer prototype over the weekend?".
- andrewstuart 4y ago
  >> not being a dev yourself you don't fully understand that this isn't a black and white issue Why do you think I'm not a developer?
  - eagsalazar2 4y ago
    Oh sorry, just assumed incorrectly I guess.
caloique 4y ago
This is counterintuitive because the more productive your development team is the more security holes they will leave behind. The thing is how to keep the productivity while increasing the security. Here is a list of OSS developer security tools: https://github.com/boxyhq/awesome-oss-devsec https://github.com/boxyhq/awesome-oss-devsec
- deleted 4y ago
  [deleted]
- mattbuilds 4y ago
  Your last 3 comments are you plugging your own startup. At least try to make it look like you want to contribute to a discussion.
  - caloique 4y ago
    Fair point, but going through the comments, I'm not trying to sell anything. One is reframing the suggested question and sharing a consolidated list of resources. The other two are on a free tool (not suggested before) to solve the problem stated, so the aim was to expand the options. But point taken ;)

pier25 4y ago

I totally agree. Stop thinking like a developer, think like a business owner. Build the MVP so that it's good enough to start solving whatever it is you're solving and get your first customers. If you can't get customers, what's the point of having a sophisticated codebase with tests, etc?

presentation 4y ago
Not even solving, just making it sellable.
andrewstuart 4y ago
>> If you can't get customers, what's the point of having a sophisticated codebase with tests, etc? And in fact every minute spent on writing and running tests (and there's always ALOT) and CI/CD is wasted, wastes money and time, leading to longer development time until the software can be put in front of users. Therefore CI/CD and tests and all their associated processes are a red flag and increases the likelihood a startup will fail to bring its software to market. Developers who have always worked in well organised environments have really deep rooted trouble getting their head around this way of thinking. If you say to an experienced developer "no tests! no CI/CD!", it's likely they will immediately decide you are an unprofessional hack.
- ryandrake 4y ago
  I met a founder with this mentality--but the problem was, the company was no longer a start-up, he had dozens of products, many (unhappy) customers, and zero development process that wasn't "writing code". He still believed every minute you spent on writing something that was not directly shipping to customers was his money being wasted. I had to argue with him to even get source control set up (he didn't agree, and I just did it in secret at night anyway). CI/CD?? Fuggetaboutit. Releases were pulled directly off the PC of any engineer who managed to get the software built without errors that day. Yes, they were usually debug builds with symbols, and never reproducible. Needless to say, it was a clown show.
  - pier25 4y ago
    Yeah the issue is adapting to what the business needs. Once you have customers the mindset should be totally different.
jiggawatts 4y ago
I use Maslow’s Hierarchy it Needs when discussing stuff like this in my consulting gig. E.g.: it doesn’t matter what fancy SIEM tool you’re using if you never patch anything and the root password is “password”. “But the vendor assured us that it would solve our security issues!” is the inevitable reply.

agrippanux 4y ago

I hear ya; you're not off on most of this. However if you're building a web service, Vercel (and its kin) make CI/CD ridiculously easy. Easy as in like 5 minutes easy, and it's worth the 5 minutes for the all the benefits.

presentation 4y ago
Yeah and most web framework init scripts even fully set up a testing framework too.
andrewstuart 4y ago
>> Easy as in like 5 minutes easy, and it's worth the 5 minutes for the all the benefits. The sum total of time spent on CI/CD and tests is not the time it takes to get it started, it's the time spent executing the tests/CI/CD into the future, thinking about the tests/CI/CD, problem solving the tests/CI/CD. All these things require ongoing time which takes time away from developing the application.
- HWR_14 4y ago
  Thinking about the tests may be an ongoing cost, but the whole point of CI/CD is that I never have to think about certain things again. That's also the idea behind the tests, but there is admittedly more work keeping the tests up to date than the CI/CD pipeline.

wpietri 4y ago

You stopped telling the story at the most interesting part. At my last startup, I wrote totally throwaway code on all our initial prototypes. Once we had something that looked like it would hit product-market fit, I hired a team, we threw away the shitty codebase and started fresh. If you don't throw it all away after making the kind of mess you describe, then you are going into the company's most crucial time with a boat anchor around your ankle and the water level rising. I'm very glad we did, as starting fresh with tests, CI/CD, and other quality practices let us be extremely responsive to my cofounder's needs and the things we learned from every release.

andrewstuart 4y ago
Getting the job done is all that matters. This is why an experienced developer is sometimes the wrong person for the job to build a startups first version, unless they are able to fully embrace the mindset of prioritising speed over everything. Beware of experienced developers who get the job of writing a startups first code and who start talking about tests/CI/CD/feature branches and all that stuff. Avoid security holes and take backups, that's all that matters and anything else should be actively avoided.
- wpietri 4y ago
  Again, you seem to be stopping the story at the wrong point. The initial job is to find out whether the project is worth investing in. 9 out of 10 startups fail, they say; if you're in one of the 9, you need to know that ASAP. If you can tell that with throwaway code, great! You've saved a shit-ton of money. As an example, I did a startup circa 2010. We raised money on an idea that VCs were very excited about. So much so that we found out later that other VCs had invested in similar notions. We spent a few months building disposable prototypes to test the value prop. It turned out that users hated the idea no matter what we tried. So we killed it after spending maybe $100k and did something else. Job done! But the other companies persevered, building full apps, and each burned millions before they realized there was no future in it. So in that case, yes, you don't want to invest a lot. But a few ideas later we had something that looked to have real product market fit. At that point, we threw away the code and started fresh with solid tests, CD, and other quality investments. Why? Because the job we were trying to do had changed. It had gone from hypothesis testing to actually serving users and building a real product. If you want to get that job done well, you can't afford to have a garbage code base.

hn_throwaway_99 4y ago

> not use CI/CD That is ludicrously bad advice. Setting up a straightforward CI/CD pipeline can take a couple hours and it instantly provides huge productivity benefits. I worked for a startup that didn't have an automated deploy pipeline and didn't have any tests. It was a complete shit show from day 1, and I will never work for that chaotic of an environment again. I am certainly not for over-engineering early in a company's lifecycle, but there are simple, "table stakes" things like use of SCM, automated builds and CI/CD pipeline. If I don't see those I assume your engineering team doesn't know how to build software fast.

andrewstuart 4y ago
The number of hours I have seen developers spend on things related to CI/CD is vast. Kill CI/CD with fire for the sake of speed. "Craptacular development mindset" is needed.
- selcuka 4y ago
  > The number of hours I have seen developers spend on things related to CI/CD is vast. Sure, same as everything else that is overengineered. A simple, no-frills GitHub Action (or equivalent) should not take longer than a few hours to implement. If you need more time than that, it means that you have an overly complicated deployment process, which is a time sink when done manually anyway.

datavirtue 4y ago

Hmmm....our startup deals with people's money. I fuck up, they can't buy gas. I prefer tests over working code.

andrewstuart 4y ago
That's a requirement of your software. Your software should meet the minimums standards required by your target user. That's the "viable" part of Minimum Viable Product. In a similar vein, you cannot release a new antivirus product that does not detect viruses, or security product that does not make things more secure. Software development has (or should have) defined priorities - and if accurate financial transaction processing is a base requirement then that's the minimum viable product you need to deliver. And if it takes tests to do that, then that's what you need.

wefarrell 4y ago

Yeah devs also don't need to use VCS, and instead of hosting it on servers just host it from a laptop using ngrok. Better yet just get rid of the code entirely and manually perform whatever tasks your users need.

kareemsabri 4y ago

CI/CD takes like 3 hours to set up and saves you hundreds of hours in deployment time. It delivers new features to your customers faster, lets you ship more frequently because you know you can roll forward quickly or revert when you mess up. Any startup founder who tried to tell their devs not to bother with CI/CD (if it's a real product, not just a prototype or proof of concept) probably doesn't know what they're doing. Being a startup doesn't mean your tech has to be garbage. So many miserable devs hoping that "after series A" they'll get to refactor that spaghetti code mess (they won't) and seeing their velocity slow to a crawl because they can't make a change without worrying the whole thing is gonna break.

robocat 4y ago

1. you are stating an opinion as fact, which is rude. Other people have facts that disagree with yours. 2. you are wildly unclear about your preconditions. I am pretty sure you are talking about the initial stages developing an MVP for a startup. Other comments are probably referring to the startup growth period following the MVP.[1] 3. You might be right in some circumstances. But your assumption elsewhere in comments that CI causes over-engineering is incorrect: any team that has an over-engineering problem will generally be in trouble, which is not caused by CI. 4. You are replying to many comments dismissively, almost attacking with your “facts”. If your argument is strong, others will answer for you. “ Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.” — https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html [1] I’m using this definition for startup http://www.paulgraham.com/growth.html http://www.paulgraham.com/growth.html — personally I dislike PG’s definition of a startup (paraphrased: designed for fast growth). Should a business that is trying-but-failing-to-grow not be a startup? A business designed for slow growth but large market is not a startup? PG gives Google as an example of a startup, yet that contradicts his own essay: didn’t Google have a lot of luck, and it isn’t obvious to me that Google was designed for growth, more that the opportunity knocked and Google jumped on that opportunity, successfully. Some of PG’s definition feels tautological; 20/20 hindsight. Edited: made politer.

andrewstuart 4y ago
>> 1. you are stating an opinion as fact. Other people have facts that disagree with yours. Agreed. I have made an error there. >> 4. You are replying to many comments dismissively, almost attacking with your “facts”. If your argument is strong, others will answer for you. “ Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.” — https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html Agreed. I have made an error there. I should choose a better tone. I do work hard to get the tone right but not successful today obviously. Apologies if this has offended anyone. I usually delete things that I feel are too negative, adversarial, preachy or otherwise not the right tone. >> 2. you are wildly unclear about your preconditions. I am pretty sure you are talking about the initial stages developing an MVP for a startup. Other comments are probably referring to the startup growth period following the MVP.[1] The comments I make are about a company pre product/market fit, doing the first build of its software before opening the doors to customers. I do agree that the startup period continues beyond this perhaps for a number of years, at which time development priorities might change. >> [1] I’m using this definition for startup http://www.paulgraham.com/growth.html http://www.paulgraham.com/growth.html For reference, in the link PG says "A startup is a company designed to grow fast.". This seems overly narrow because it seems self evident that there is lots of startups that have different objectives to fast growth. My definition for a startup is more like Steve Blank's: “A startup is a temporary organization designed to search for a repeatable and scalable business model.”

eagsalazar2 4y ago

Chaos has a cost too. You need to weigh that against the cost of testing. And both chaos and testing cost exist on a very broad continuum. For very trivial prototypes, spending even a few hours on tests obviously outweighs any benefits. And 100% unit testing coverage never pays off even on larger projects. However a few hours of setting up CI/CD with linting, type checking, required reviews, automated deployments, and yes some sanity checking integration tests, can provide massive velocity benefits that pay back the investment in a few days and are pure velocity windfall thereafter. I think you (a) have been burned (and I'm not denying testing can be a waste of time) and (b) not being a dev yourself you don't fully understand that this isn't a black and white issue or that you are actually paying a massive velocity cost by doing zero testing. Your POV is akin to advising people to not drink water on a hot, strenuous hike because "every time you lift your arm to drink, you are wasting energy that could go to your legs". Uh yeah, in both cases it's a little more complicated than that. Definitely don't waste an hour making a gourmet meal (and yes I get sometimes devs do this), but there are a spectrum of options and there is a sweet spot. How about "drink some gatorade and eat a power bar without slowing down"? Getting that balance right isn't trivial but it is possible and the payoff is huge. Which goes to the other point you made about not hiring expert devs, man, you've been hiring the wrong experts if you think fresh, unsupervised bootcampers are a better choice at any stage other than "can you make me a framer prototype over the weekend?".

andrewstuart 4y ago
>> not being a dev yourself you don't fully understand that this isn't a black and white issue Why do you think I'm not a developer?
- eagsalazar2 4y ago
  Oh sorry, just assumed incorrectly I guess.

caloique 4y ago

This is counterintuitive because the more productive your development team is the more security holes they will leave behind. The thing is how to keep the productivity while increasing the security. Here is a list of OSS developer security tools: https://github.com/boxyhq/awesome-oss-devsec https://github.com/boxyhq/awesome-oss-devsec

deleted 4y ago
[deleted]
mattbuilds 4y ago
Your last 3 comments are you plugging your own startup. At least try to make it look like you want to contribute to a discussion.
- caloique 4y ago
  Fair point, but going through the comments, I'm not trying to sell anything. One is reframing the suggested question and sharing a consolidated list of resources. The other two are on a free tool (not suggested before) to solve the problem stated, so the aim was to expand the options. But point taken ;)