Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Talk to Corp Dev (2015)

paulgraham.com

Post reply on HN
Print view View original

101–110 of 127 posts

Re: Don't Talk to Corp Dev (2015)

#101

Post by rsj_hn »

orf wrote: post #41
rsj_hn wrote: post #24

Earlier quoted context omitted.

These words "secure" and "insecure" when used as synonyms for "encrypted" and "plaintext" obscure more than they illuminate and have done a lot of damage to the world of software security. They stop thought. You would not believe how many times I've talked to a company with some complex webapp and asked for their security policy and they respond with some statement about using TLS. It's absurd. Then even in books or…

In the era of instant, free and stupidly easy to configure TLS certificates why not just serve it over HTTPS?

It's definately easier nowadays to do it, but you still have the issue of services becoming unavailable because certs expired - something that routinely happens, so it adds some operational overhead that - in the examples I described -- provides no benefit. This operational complexity is there even if the certs themselves are free.

More importantly, security theater is something that should be avoided as it creates bad habits and promotes irreality in a field already rife with the same. I'm not sure why cryptography struggles so much with this, but there are a lot of people who don't understand what benefits, if any, cryptography provides to their application but decide to add it in anyways.

This should be considered a bad practice. Imagine if someone told you to add a function to a codebase just because other codebases had it, and what harm can it do, even if this function served no purpose and doesn't require too many CPU cycles. Most software developers would oppose the idea, they would want to add code only when it is needed, and would favor the removal of unneeded code as beneficial, given that this simplifies the codebase. The same is true for encryption, which requires a lot of CPU cycles, and adds non-trivial complexity. So the idea that it should be added everywhere even where it's not needed is something we should resist.

Re: Don't Talk to Corp Dev (2015)

#102

Post by mihaaly »

duxup wrote: post #42

>If they can, corp dev people like to turn the tables on you. They like to get you to the point where you're trying to convince them to buy instead of them trying to convince you to sell. I worked for an established company (not a startup) and had a run in with Wal-Mart. Wal-Mart managed to buy some stuff at an ultra low discount because ... someone thought maybe if we get in there we could sell tons to their IT team…

I wonder if there are any gropus out there anymore with the intention of becoming successful by making good product for users, serving the client? I read articles like this, stories like yours, talk to startup owners recruiting who answer "Sold to someone." when you ask them "Where do you see your company in 5 years?" and I have doubt the product and users are in focus. And organizations proud themself being series n founded next to or before the success of their product (which many time is just missing in fact). Seems like product and users, the functionality is an unavoidable circumstance only, one of the many, something to consider like office space or tax returns. I don't know why but somehow the Boeing story comes to mind, how they shifted focus from engineering to business in the passenger plane line when McDonnell Douglas managers bought themselfs into Boeing management with Boeing's money. And the 737 MAX.

Re: Don't Talk to Corp Dev (2015)

#103

Post by ChuckMcM »

The only response you should make to these sorts of things are "Give me a number, if it is close we can go to the next step." That is it.

If they give you a number, then you say "Put it in a MOU where you will pay us 10% of that number if these discussions break off for ANY reason."

Only after you have a number you would actually sell the company for, and you know that if they are wasting your time you will still get enough cash to cover the extended runway you will need to keep going after they leave, then it is possible they have enough skin in the game to be aligned more with your interests.

Re: Don't Talk to Corp Dev (2015)

#104

Post by kevin_thibedeau »

doctor_eval wrote: post #68
quickthrower2 wrote: post #66

Earlier quoted context omitted.

I've worked at a small company constantly chasing large customers. Let's say a middling customer deal was $50k. Pretty much all profit. A large customer deal would be $500k, and need $500k of very specific technical-debt inducing bespoke dev work. I didn't know why they didn't grow the number of $50k deals! Actually I know why. It was the "If we can get walmart it'll lead to much more" mentality (but not walmart but…

Sounds like where I ended up. We had a moderately successful company doing a lot of ~$100K deals and once we became financially sustainable we merged with a supposedly larger company in a complementary field with a view to accelerating our sales and getting access to a larger and more experienced tech team. It turns out that they didn’t care at all about our regular little deals - the sales lead bragged to me once th…

I worked for a defense contractor that turned their nose up at $200M NASA contracts. Then after shenanigans from an unrelated division of the parent company all the big contracts started to dry up as punishment.

Re: Don't Talk to Corp Dev (2015)

#105

Post by tester756 »

CamelCaseName wrote: post #81
tester756 wrote: post #54

>Don't Talk to Corp Dev it sounds kinda edgy, especially that "corp dev" bonus points that "dev" seems to refer more often to "developer" than "development"

No, Corp Dev is definitely "Corporate Development". No one outside tech in this field would ever think of "Dev" as "Developer". It's not edgy at all. It's just the name for the job. This is how people refer to themselves as. E.g. "I work in corp dev".

>No one outside tech in this field would ever think of "Dev" as "Developer".

Who's the majority of audience of PG's posts?

Re: Don't Talk to Corp Dev (2015)

#106

Post by ToJans »

We are currently talking with a few potential buyers for our SaaS, and had talks in the past as well... Here's my lessons learned:

One didn't proceed at the very last step, without any explanation or feedback, so I have become very careful when engaging into these kinds of conversations.

All of our serious negotiations are small and medium sized organizations, both customers and competitors where we can extend their offering or have an important tool that generates a lot of their leads, so we usually don't reply to exotic candidates.

We had a few chats with large organisations, but this was mostly a bullying kind of relation, so we did not proceed... I think this is a bit like a poker game: to maximize your odds of winning you need to play in your own league...

The advantage is that, in this "little league”, discussions tend to take anywhere from 3 to 5 meetings and some emails, nothing more; that's the advantage of talking with the company owners directly and not with a big-corp M & A cell...

IME you can be blunt and open, and I strongly suggest to avoid a technical due diligence until the latest phase.

No need to exaggerate numbers, just be open and explain your valuation model; this might be anything, but it needs to buy them good ROI, time, a competitive advantage or a decrease in risk. IME it works the best if they have the capacity to scale up your product, so it's a win-win.

I haven't considered a 10% deposit, but I think this might be a bit too aggressive for European standards in the early talks. However, I think it is a good idea to go through with it once you have an LOI.

It is a challenging process that's not over until the fat lady sings, so try to manage your expectations and be prepared to walk away if it is not a win-win. If you fail to see what their motivating factors are in the deal, just walk away...

Re: Don't Talk to Corp Dev (2015)

#107

Post by orf »

rsj_hn wrote: post #101
orf wrote: post #41

Earlier quoted context omitted.

In the era of instant, free and stupidly easy to configure TLS certificates why not just serve it over HTTPS?

It's definately easier nowadays to do it, but you still have the issue of services becoming unavailable because certs expired - something that routinely happens, so it adds some operational overhead that - in the examples I described -- provides no benefit. This operational complexity is there even if the certs themselves are free. More importantly, security theater is something that should be avoided as it creates b…

In the time it took you to write this reply you could have set up an auto-renewing certificate for your site with let’s encrypt. Or you could have pressed a button and have it served behind cloudflare.

The nuance of if encryption is really required in this specific case is pointless when it is so easy and readily available. The effective direction becomes “just blanket serve everything over HTTPS” because there isn’t much downside.

Re: Don't Talk to Corp Dev (2015)

#109

Post by gambiting »

LgWoodenBadger wrote: post #94
gambiting wrote: post #86

Earlier quoted context omitted.

I'm genuinely curious - how? On both of these points. It's just a simple text page, why would this ever need https at all?

How do you know what you read is actually what pg wrote?

I don't know, how do you know someone hasn't hacked into his server and changed the text there even if he had HTTPS? There are things to worry about, and there is a simple text blog not using HTTPS.

Re: Don't Talk to Corp Dev (2015)

#110

Post by enriquto »

enzanki_ars wrote: post #26
yellow_lead wrote: post #20

Earlier quoted context omitted.

Many read only sites don't have HTTPS. Firefox and other browsers are at fault for saying it's insecure.

For a good discussion into why _all_ websites should use HTTPS, I'd highly recommend this article. https://www.troyhunt.com/heres-why-your-static-website-needs... Not having your site as HTTPS puts all of your readers at risk. Even US ISPs like that of Comcast use this very same practice to inject warnings into insecure web traffic[0]. And like mentioned in the article, promises from ISPs not to use it for advertisem…

This article is controversial and shows a distorted and incomplete point of view. For example, https sites are more vulnerable to some types of censorship. A CA can censor your site by unilaterally revoking your certificate. It routinely happens already. Promises from CAs not to censor you are just that, promises, and those can be broken in an instant.
Post reply on HN