Hacker News Reader

Comment by andrewstuart | Hacker News Reader

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.

View on HN

> 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.

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.

> 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.

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?".

>> 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?

Oh sorry, just assumed incorrectly I guess.

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

[1] I’m using this definition for startup 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.

>> 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

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

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.”

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.

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.

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.

"But the other companies persevered, building full apps, and each burned millions before they realized there was no future in it."

I like these companies. Share the names and I'll have my sales guys reach out.

Kudos, if you actually did that rewrite.

...if only I had a cent for every time I've had this conversation with an engineering manager: Manager: "Just live with the mess for now. We'll fix it later when we have money." Later: "Can we fix the mess now?" Manager: "No. We're making too much money now. Blah, blah, blah. Opportunity cost."

We really did throw it away. And when I'm an engineering manager, this is my big test for product managers. Initially I give them a low-limit credit card for technical debt. If they pay it off when they promise, I give them a bigger limit. If not, I take the credit card away and we keep a consistently low level of technical debt.

And I should add that more startup and new-product teams should be bold about throwing away code. Startups need to be optimized for learning. Each release should tell you something about your users, your market, your ideas. But doing that means that some of the code will have been written before you know what you're doing. That code either needs to be refactored or reverted. The latter feels scarier but is often cheaper.

Couldn't agree more.

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.

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?

>> 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.

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.

Yeah the issue is adapting to what the business needs. Once you have customers the mindset should be totally different.

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.

Not even solving, just making it sellable.

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

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.

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.

Yeah and most web framework init scripts even fully set up a testing framework too.

>> 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.

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.

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.

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

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.

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 ;)

Reply on news.ycombinator.com