Why's it so hard to find "your clothing size"? - <AUTHOR> https://www.tryfitfirst.com/home/whats-my-clothing-size <comment><USER2> My professor uniform used to involve a closet full of Brooks Brothers Oxford button-down shirts. Not that the brand resonates with me; the quality was simply better than similar mass-produced shirts. They felt like the denim shirts I was advised to not wear.

Then I discovered propercloth.com - custom shirts made in Asia, with an outpost in Manhattan. Took a guess at the dozen or so size parameters, got my trial shirt, wore it down to their tailor, and had it tweaked. Turned in my trial shirt for a free replacement. I now have 15 or so.

I wish one could do the same with jeans.

<comment><USER3> There was a thread the other day about quality vs fast-fashion the other day. [https://news.ycombinator.com/item?id=20503194](https://news.ycombinator.com/item?id=20503194)

There are a some mentions of some better brands out there. Proper Cloth was one, but there are others, even ones which make bottoms.

</comment></comment><comment><USER4> The problem is best understood from a supply chain management perspective.

A clothing retailer ordered that stuff six months ago and they only took a two minute glance (if that) at the one model sized 'medium' garment the wholesaler got the supplier to make. Every other size was just a tickbox with some guesses made as to how many items to stock to get through the sales season.

The importer took the orders from retail and topped up the order so they can do some mid-season re-stocking. They know that they have to get the order right as it is not as if the product is going to be made again.

The retailer does not have to make a sale from every customer that walks through the door. For people with XXS or XXL size requirements they might only have something to sell, the one coat in the super-sized option. Even this may be a carryover item from a previous season, kept in stock for the guy with arms that reach down to his ankles.

It is quite a risk to get the sizing wrong, you can't have a garment on the shelves with just the XXS and XXL sizes with nothing in-between. If this happens then it is straight to the sale rail. Particularly if the supplier didn't overstock the popular sizes.

We also live in an age of fast fashion where people buy clothes the whole time. Truth be told, if everyone out of childhood stopped buying clothes today we wouldn't have a mass nakedness problem for years. Clothes are that abundant. There have always been tailors and dress makers that will make clothes to fit any body, maybe a service for this is needed rather than a newsletter about what trousers in the world of fast fashion can be squeezed into.

</comment><comment><USER3> This happens in women's clothing but also men's. The only piece of men's clothing which doesn't reinterpret measurements is belts. Which is why they tell you if you're an X waist, get an X+2 belt. It's much worse with letter sizes. There is no consensus. —even within brands.

<comment><USER5> It's not even consistent with belts. They have vanity sizing for men as well. Last I checked, Old Navy was waist size plus 4 inches for belts.

<comment><USER6> Besides, with belts you need to get lucky with the hole placement.

<comment><USER7> at least you can cut your own holes pretty easily

<comment><USER3> An oval punch would work well.

</comment></comment></comment></comment></comment><comment><USER8> You think that's bad? Here's Europe:

NL DE FR IT SP GB US International

32 32 34 38 0 4 2 XS

34 34 36 40 1 6 4 XS

36 36 38 42 2 8 6 S

38 38 40 44 3 10 8 S

40 40 42 46 4 12 10 M

42 42 44 48 5 14 12 M

44 44 46 50 6 16 14 L

46 46 48 52 7 18 16 XL

48 48 50 54 8 20 18 XXL

50 50 52 56 9 22 20 XXL

52 52 54 58 10 24 22 XXXL

</comment><comment><USER9> Stop the madness, use EN 13402 labels already!

</comment><comment><USER10> Huh... TIL Farm Rio in also in the US

</comment><comment><USER11> Why it's so hard to find text-only static article sites which render with JS disabled.

</comment><comment><USER12> This is one of those "no stupid questions" type questions: why are there so many more sizes for women? Men's sizes don't fit perfectly either, but it seems like women have more sizing options for the same struggle. Are women harder to fit? Do men just not bother with a correct fit? It also seems that at least a good number of guys can wear off-the-rack for a decent fit, but almost no women. Just a guy who doesn't understand trying to understand more.

And while I'm it, many women I know don't wear dresses more than once or twice. Why? This seems wasteful.

<comment><USER13> > _why are there so many more sizes for women?_

There aren't.

Go down to a basic clothing store like The Gap and look at the different pants options available in the men's section. Skinny, Slim, Straight, Relaxed, Athletic, and Jogger aren't just different styles. Each style also fits differently at the same nominal measurements, because the nominal measurements for pants are waist + inseam but there are many more measurements that actually matter, like the ratio of your waist to thigh to calf. Pants that fit your waist might not fit your legs. Pants that fit your legs might be too tight in the waist.

If a 30 Relaxed fits you, a 30 Slim probably doesn't. They aren't just styles. They are different kinds of sizes with names.

> _And while I 'm it, many women I know don't wear dresses more than once or > twice. Why? This seems wasteful._

Come on. Don't be a sexist caricature.

> _It also seems that at least a good number of guys can wear off-the-rack for > a decent fit_

In my experience this is false. It depends, of course, on what you're willing to accept as "decent fit". I personally, for instance, would not accept a dress shirt that billows like a sail around the waist as a "decent fit". And yet good luck finding a rack men's dress shirt that doesn't do that if you are fit but not rail thin across the chest.

<comment><USER12> I don't go to stores like gap, and don't really buy trendy clothes. I've never seen tons of styles like all those you mentioned, especially not in one place. My jeans are usually $20-25 a pair; I buy on-sale.

I've also never really heard of the "raito of waist to thigh to calf" being used as a measurement.

Maybe these sorts of things are popular among the younger "metrosexual" boys?

> Now you're being a sexist caricature.

How? Caricature of what? I'm relaying the exact things I've heard and seen from others. I'm really just asking a question, more "why is there this expectation of women?", and you cry "sexism"? That term is very overused.

<comment><USER14> To be honest, you sound out of touch. Especially with the dropping of the "metrosexual" line.

You asked why there aren't more sizes for men, received a response telling you there are, and then somewhat indignantly responded with "well, I don't shop at those places." Well, if you want to find a better fit, maybe you ought to.

Old Navy (parent to Gap) sells a variety of jean sizes for a fairly low price: [https://oldnavy.gap.com/browse/category.do?cid=5199&nvt=Hamb...](https://oldnavy.gap.com/browse/category.do?cid=5199&nvt=Hamburger%20Nav&nvt=Men&nvt=Shop%20by%20Category&nvt=Jeans)

<comment><USER12> I am probably out of touch, but I wish more people would respond with information, not rebuke.

I thought metrosexual was the politically correct term these days, and that the terms traditionally used for such people are now considered offensive. What is a better word?

I get a perfectly good fit, which is why I don't shop at such places. I asked because I didn't know such things were commonplace for men, precisely because I don't shop at such places. That part of the answer was informational, and something of which I was simply not aware. The "sexist caricature" part was what merited the indignance.

Honestly, it seems as though I'm being rebuked simply because I'm not a fashionista. The first respondant referred to Gap as a "basic" clothing store; I always thought of it as high-end. I didn't grow up in a situation where we shopped at exoensive stores: not poor, just not _that_ rich. I never fell out of those habits, I guess.

<comment><USER14> It's not the fact that "metrosexual" is or isn't politically correct (I really don't know (or care) where it falls), it's more the fact that the term itself is passé. It's a term that was used (and overused) some 15 years ago. Plus, it referred more to a man that over-indulged in taking care of their appearance, not a man that is just looking for some good fitting clothes (which is the subject of this discussion...I think).

Anyway, the more you know -=*.

(Also, no foul intended. I'm well on my way to being out of touch, too.)</comment></comment></comment></comment></comment></comment>


10 things you (probably) didn't know about Go (2012) - <AUTHOR> http://nf.wh3rd.net/10things/#1

<comment><USER2> Not sure how this got linked. The talk is not hosted there anymore (and hasn't been for some time). Here's its actual location:

[http://talks.golang.org/2012/10things.slide#1](http://talks.golang.org/2012/10things.slide#1)

<comment><USER3> The submitted link works for me.

<comment><USER4> It sometimes worked for me. The server's likely overwhelmed. The Coral Cache link works consistently:

[http://nf.wh3rd.net.nyud.net/10things/#1](http://nf.wh3rd.net.nyud.net/10things/#1)

<comment><USER2> It's not overwhelmed. There must be a bug in my web server!

</comment></comment></comment></comment><comment><USER5> Nested structs are really neat. I'm working on a project where I'm querying dozens of external API services, and I had to create a separate type structs for each JSON object just to get the interesting info nested in the response.

I wonder why he's using a chan struct{} for the quit channel. Is there a reason for that? Is it more efficient?

Usually I use a boolean for that:

        quit := make(chan bool)
        <some code>
        quit <- true

<comment><USER6> I believe the empty struct is marginally smaller than a boolean.</comment></comment>


Thumbtack: The New Go-To site for busy individuals - <AUTHOR>

A couple of days ago, my sister's computer gave up on her. The screen blacked out and when we tried to turn it on, the light of the power didn't even come back. Now since we're both working, we had no time to bring it to the repair shop. Luckily, our smart cousin has an account at Thumbtack and booked a professional for us.
According to my mom, the computer repair guy came in complete uniform, in fact he was wearing his ID AND name tag.  After about 30 minutes, my sister's laptop was up and running again. My cousin was with the repair guy the whole time and he was sure that the repair guy did no hocus pocus. Whew, issue solved.
You can visit their website at www.thumbtack.com. It's a pretty neat site, user friendly too. I also got the chance to browse their site and it says their looking for good engineers. Anyone interested should check out their job listing at http://www.thumbtack.com/jobs. Who knows? You might just get that job! <comment><USER2> This feels like a sham review for Thumbtack phishing for users on HackerNews.

<comment><USER3> Nah... nah this is totally legit.

He didn't copy and paste it, including html formatting, from a pre-canned document.

He certainly didn't make a second post a few seconds later stating how great thumbtack is to use either...

Nah... Totally legit

</comment></comment><comment> saiko-chriskun id AND name tag folks!</comment>


Monorepo is great if you're really good - <AUTHOR> https://yosefk.com/blog/dont-ask-if-a-monorepo-is-good-for-you-ask-if-youre-good-enough-for-a-monorepo.html <comment><USER3> > the entire code base got forked, and the entire org is now held hostage by > the dumbass.

> Of course in a Good team, needless dependencies would be weeded out in code > reviews, and a Culture would evolve over time avoiding needless > dependencies.

Really, the one consistent thing is that if you have a good team, you'll make it work no matter what tech or decisions you make (assuming you're also good enough to know when you've lost and change course), and if you're a bad team, you're doomed to failure, because, well, you're bad (by definition).

I think this article also vastly underestimates the cost and annoyance of the tooling of CI'ing a large number of repos, especially if you have to match or do some kind of cross product on the feature branches. (such as, repo A branch B can only be built with repo C branch F, but all the other repos should be master)

<comment><USER4> >> Of course in a Good team, needless dependencies would be weeded out in code reviews, and a Culture would evolve over time avoiding needless dependencies.

Heh. This reminded me of a different story, which I remember vaguely enough that I'll paraphrase from memory:

> "The Excel team will never go for it. Their motto is 'Find the > dependencies... and eliminate them.'"

> This probably explained why the Excel team had its own C compiler.

<comment><USER5> Sounds like Joel on Software.

<comment><USER6> [https://www.joelonsoftware.com/2001/10/14/in-defense-of- not-...](https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented- here-syndrome/)

</comment></comment></comment></comment><comment><USER7> Is the monorepo/multirepo choice really the most important thing to consider?

Branching: monorepo or not, if a feature-incomplete development branch for one of the supported targets can "hold the entire organization as a hostage" then the SCM people, and/or persons responsible of the SCM policy, should do some introspection...

Why are deliveries done from a branch which is obviously still in development? Why does code-to-be-released need to depend on incomplete work? Why aren't something like "topic branches" used?

Modularity: monorepo or not, problems will certainly appear when the complexity of implementation outpaces the capacity created by the design. To get modularity, one needs actual modules with properly designed (=not brittle, DRY, KISS, YAGNI, SOLID, etc. etc.) interfaces between the modules. Now, does monorepo/multirepo really play a role here at all? If everyday changes are constantly modifying the module interfaces in incompatible ways which breaks existing code, this speaks something about the design, or rather the insufficiency of it.

Of course, every project and team is different. However, even if a locally optimal choice for the monorepo vs. multirepo question is found, problems existing regardless of monorepo/multirepo will still be there.

<comment><USER8> I was wondering the same thing. Like, I use a microservice architecture at work, but the choice of using one vs. many git repos to represent diffs in those services over time seems largely meaningless. I don't like large diffs or people breaking production, but this is solved by testing and insisting upon small diffs, not by how many git repos we use.

Formally speaking, multi-repo management allows a strict subset of the diffs allowed to a mono-repo (because diffs can 't extend beyond each repo root). Are the excluded possibilities all bad? No. Are they generally bad? Not really. Are they sometimes bad? Sure. Are they sometimes better than many diffs across many repos? Sure. Can a reasonably competent dev team tell the difference? Sure, usually. Unsurprisingly, this usually requires the exact same tooling as ensuring the quality of microrepo changes.

If you're continuously deploying master, have a healthy ci/cd pipeline, and enforce good merging discipline, you're fine either way.

I'm a little tired of doing things like revving our trace and logging libraries across our 50+ micro repos that represent microservices. That's genuinely obnoxious. Is it bad? No. Is it obviously more or less error prone than the equivalent monorepo update? No. All the bad bits of either strategy just require some tooling and a clear head.

</comment></comment><comment><USER9> My team just switched to a monorepo. It's been only a few weeks, so I can't claim any results yet, but we've lived w/ the pain of poly-repo for long enough that we were ready to invest in a single repo.

We've spent a lot of time building and iterating a unified ci/cd environment to support the new repo. Previously each project had it's own test/deploy/build/publish story and usually it's own jenkins project. Now, each project is registered and triggers its own steps. Cross-project edits can happen in a single pull request. We have an incredible amount of integration tests (more so than unit tests), and getting them to work corss-project while migrating has been challenging.

We've gone from ~10-15 actively maintained repos to about 3 as we're slowly migrating. We have a mix of services, libraries, and batch processing all mixed in.

The authors points about forking and long-lived branching being incredibly difficult for most teams is really crucial. We're going to have to invest in education for new members about WHY we have a monorepo, what it means for your development, and how to change your perspective for developing at HEAD. I don't think 'bad' developers make it easier or harder. Instead, clearly articulating behaviors that exist in a poly-repo vs mono-repo world to developers is the Differentiator.

These articles were absolutely crucial to developing our monorepo.

[https://trunkbaseddevelopment.com/](https://trunkbaseddevelopment.com/)

[http://blog.shippable.com/ci/cd-of-microservices-using- mono-...](http://blog.shippable.com/ci/cd-of-microservices-using-mono-repos)

[https://www.godaddy.com/engineering/2018/06/05/cicd-best- pra...](https://www.godaddy.com/engineering/2018/06/05/cicd-best-practices/)

<comment><USER10> How do you handle building changes to just one of those projects? Can Jenkins do that (easily)?

I think that's the big thing that always puts me off monorepo... We'd basically be going from ten 5 minute builds to one 50 minute build if it wasn't possible to do incremental builds. IIRC Google and MS have purpose built tools that do impact detection to work out what to build for their monorepos to keep build times down.

<comment><USER11> If you're doing a monorepo I think it's strongly implied that you'll also use a build system (Blaze/Brazil/BuildXL etc) that has granular compilation units and output caching so build time doesn't scale linearly with the company's total codebase.

It's definitely important to consider before jumping in. Going from 5m to 50m compile times would be a major issue for me.

<comment><USER12> Err what is even the alternative? Even a makefile would provide incremental builds.

<comment><USER13> A _good_ makefile provides incremental builds in _every possible scenario_ of source file changes. It's very easy to write bad makefiles that don't catch modified or removed header files, or even worse when code generation or other complicated build logic is involved. Because a lot of developers seem to think "random build fail? oh just do make clean" is an acceptable workaround.

</comment></comment></comment></comment></comment><comment><USER14> Linus Torvalds said something about this, in relation to microkernels. But the gist is in how interactions between many pieces makes the whole thing complex. Here's the quote from his book "Just for Fun".

"The theory behind the microkernel is that operating systems are complicated. So you try to get some of the complexity out by modularizing it a lot. The tenet of the microkernel approach is that the kernel, which is the core of the core of the core, should do as little as possible. Its main function is to communicate. All the different things that the computer offers are services that are available through the microkernel communications channels. In the microkernel approach, you're supposed to split up the problem space so much that none of it is complex. I thought this was stupid. Yes, it makes every single piece simple. But the interactions make it far more complex than it would be if many of the services were included in the kernel itself, as they are in Linux. Think of your brain. Every single piece is simple, but the interactions between the pieces make for a highly complex system. It's the whole-is-bigger-than-the-parts problem. If you take a problem and split it in half and say that the halves are half as complicated, you're ignoring the fact that you have to add in the complication of communication between the two halves. The theory behind the microkernel was that you split the kernel into fifty independent parts, and each of the parts is a fiftieth of the complexity. But then everybody ignores the fact that the communication among the parts is actually more complicated than the original system was—never mind the fact that the parts are still not trivial. That's the biggest argument against microkernels. The simplicity you try to reach is a false simplicity."

<comment><USER15> > "...The simplicity you try to reach is a false simplicity."

Also applies to some microservice architectures I've seen. People completely disregard the complexity (and overhead!) of the interactions between microservices.

<comment><USER16> I feel like I've become a crusader against microservices for the same reason.

They're so easy to set up and they immediately solve problems. But they also create many more, which aren't immediately obvious. And very few people are willing to say, "I was totally wrong to move to them, and let's spend some more precious time rolling them back."

<comment><USER17> As somebody who built some stuff with microservices before, I think the key is, that you don't view any architectural pattern as a silver bullet. All things come with their own trade offs.

It can make totally sense to break out certain parts into their own microservices if you thought long and hard about the interface and which data is going to be passed around – but if you break things out into their own microservices just for the heck of it, you will end up in a very messy mess quickly.

Using microservices to solve problems which don't demand them is similar to using OOP patterns in places where they are known to bring pain: you are holding a hammer and you think the world is made of nails.

That beeing said I am sure this has nothing to do with the real practicality of the underlying patterns, it just shows how easy people can lie to themselves.

</comment></comment></comment></comment><comment><USER18> >>>* They don't like to have to clone lots of other repos, and to then worry about their versions (in part because the tooling support for this might be less than great).*

I think this is the argument around which the whole post is made. Everyone does want to work in a small space where they control everything. I want to see git log with just my code commits - so I'll make a microservice out of it.

All other arguments are just there to wrap this one. I think it's wrong.

At an organisational level, a monorepo is more good than bad because it simplifies dependency management and makes for a low-ego team.

<comment><USER19> Counterpoint: monorepos make it easier to neglect packaging and dependency management since it's mechanically possible to assume any files in source control are on-hand. This makes it trivial to have implicit dependencies and see the uglier implications of Hyrum's Law.

</comment></comment><comment><USER20> I don't agree with the author that the quality of the team is what determines if a mono-repo is appropriate or not. It doesn't really matter if you use a mono-repo or not, what matters is what individual engineers are empowered to do.

If engineers or even team-leads don't have permission to create a repo themselves well then you're probably going to see benefits from a monorepo.

At the same time if you have say a ~100 people sharing a repo then you have to make sure that you have tooling that allows each team to customize their building and test environments themselves, which is hard because many CI solutions assume that One Repo = One Build status. Implicit in the author's reasoning is the principle that good engineers don't make mistakes; they don't break the build, not ever. But of course they do, everyone does, and if you have a hundred developers builds will be broken and people's productivity ruined.

Perhaps because we're an industry so prone to failure we keep looking for that one solution, that given a good team makes all problems go away. Agile, XP, Monorepos, Containers, Microservices: we tell ourselves will solve our problems and get those pesky business people off our backs for good. But they won't and never will.

What really matters is enablement, how can we get our code into production doing what it was intended to do without having your toes stepped on all the time. If you design your processes and tooling around enablement not the cargo-cult flavour of the month buzzword invented in the modern beautifully architected, yet completely open office spaces of one of the FAANG companies, then maybe then you can get some actual results.

<comment><USER21> > Implicit in the author's reasoning is the principle that good engineers > don't make mistakes; they don't break the build, not ever.

They don't, ever, because the VCS refuses a push if it breaks the build.

That's the problem with all those single-repo discussions. It works perfectly well if you have all the tooling that makes a single repo work like a multi- repo.

And it's great because you can enforce behind the scenes that everything is coherent... Except that you can enforce the same thing on a multi-repo if you write the equivalent tooling. All the points are completely moot, except the one that if you don't have a ton of tooling, a single-repo won't work at all, while a multi-repo will just be not great.

<comment><USER22> I actually tend to find the opposite - with a multi repo, CI/CD is often just plain broken and people waste significant amounts of time cargo culting working setups (and often do so badly or don't keep up with upstream changes).

</comment></comment></comment><comment><USER23> > Monorepo is great if you're really good, but absolutely terrible if you're > not that good. > Multiple repos, on the other hand, are passable for > everyone – they're never great, but they're never truly terrible, either.

The calculus is trickier than this.

He thinks the above is true because of this other thing he says:

> With multiple repos, modularity is the norm.

But if this were true, being "Good" would be easy. I wish programming tools were this able. Then I could go to the pool every day!

But just because you're using some feature of a build or programming system -- like modules or classes or namespaces -- doesn't mean you get the win. Certainly doesn't mean you know how to wield these tools.

In the end the technical feature doesn't save you. You actually have to have a hard-earned skill, which is how to properly modularize code into stable components with narrow stable interfaces and all of that. This skill is very rare ime.

Now back to monorepo vs modules.

If you use modules but you suck at modularization you're going to be paying a huge tax. Because you'll be creating volatile code/interfaces and you'll have to go through a process each change. You will be amplifying the tax from your lack of skill that you wouldn't if you were just in a single monorepo.

On the other hand if you use a monorepo and you suck, you won't experience ^^this^^ pain and you'll be at a much higher probability of staying sucking.

In short, programming language and build features don't bestow skills.

</comment><comment><USER24> Its funny and makes some good points but I don't think the distinction is between good and bad teams but whether or not you're 1 team or more.

If one team has one application that is split across multiple repositories it can be a productivity boost and a simplification to unite them into a single repo with some single tools and norms.

If you have two teams working primarily on two sets of repos and two different systems or applications, by all means split them into two (or more) repos. Just be cause its called a "monorepo" doesn't mean you can't have more than one!

It may be simpler to have one, it may be simpler to have many. Do whats simpler for you! I happen to think that it primarily depends on how your teams are organized more than on who is in the teams or their "badness" levels.

<comment><USER25> I think this only works if the teams are actually working on different products. If Team A and Team B are both writing to and reading from the same data stores, then I'd say they're likely both working on the same product, and you have a multirepo.

</comment></comment><comment><USER26> > What do you do when you have a branch working on Android and another branch > working on iOS and you have deliveries on both platforms? You postpone the > merge, and keep the fork.

Honestly, it never occurred to me that you're deploy from more than one branch. If you can't merge the branches into <your main branch that releases are built from>, then what's in the branch doesn't make it into a release (from my experience).

<comment><USER27> Seriously, this part threw me hard. Having multiple active forks is not something that's ever been considered as an option anywhere I've worked. Worse, I'm not convinced multi-repo even fixes this issue if you already have a culture that allows multiple active forks.

For instance, big app rewrite, half-new REST API on the backend. Oh, but we need to maintain the old app APIs for those who can't update (like SuperImportantCustomer). Better fork!

<comment><USER28> I suppose it depends on your definition of "active" here but having release branches for previous major versions that are still supported with things like backported security fixes etc. is a pretty common setup.

</comment></comment></comment><comment><USER29> Does anyone here have experience using submodules to tie individual repositories together? We've been using this in our small startup (only a few developers) and so far it works nicely. It allows us to check out and develop repositories individually but at the same time maintain an exact dependency graph for our entire system. You can for example have a single repository that ties together different projects and has submodules that contain specific references e.g. to the frontend, backend and deployment repositories. You can then use this master repository e.g. for deployment and integration testing. Gitlab makes CI/CD in such a setup very easy and checks out submodules recursively during a build, even across groups.

The drawback is that not many people are familiar with submodules and they can be a bit tedious to set up, though working with a submodule is almost like working with a normal file in git. One danger is of course that branching between individual submodules can get messy. Another nuisance might be that you have to commit recursively, i.e. if you have one repository with a submodule to which you make changes you need to first commit these changes in the submodule and then create a new commit in the parent repository that adds the new version of the submodule. Maybe this is a good thing though as it forces you to commit changes individually in each submodule before committing a larger change into your main repository. In general I would avoid nesting submodules more than two levels deep, as this can quickly get confusing.

In the past I've also worked on a large mono-repositoriy and enjoyed it as well, just curious to hear if anybody has used submodules in a larger team.

<comment><USER30> I have bad experiences with submodules. It was only one submodule just one level deep, and it only contained something like a convoluted configuration shared among multiple repos.

As you say, getting a change first into the child and then into the parent requires double PRs and testing. But that's the same as if you had it as a package dependency. Only that instead of a version, you have a sha1 which you never know what it is.

I prefer package dependency, because it forces you to explicitly make a release, where it should have passed PR and some integration tests. Also merge conflicts are clearer.

</comment></comment><comment><USER31> That is very, very subjective

> With multiple repos, modularity is the norm. It's not a must - <USER2> > technically can have a repo depending on umpteen other repos. But your > teammates expect to be able to work with their repo with a minimal set of > dependencies.

You'd think so.. but no. I am working with multi-repo project where some repos have about dozens of dependencies, all developed locally, and interdependent on each other. Bumping the basic repo is very hard and frustrating. I miss my monorepo every day, where I could just make a PR and fix all consumers at once, where I had a CI which would test all modules at once.

</comment><comment><USER32> One interesting new thing in this post that I've not seen in this debate is that polyrepos tend to enforce acyclical dependency graphs.

All monorepo projects I've ever worked on enforced the same either through the language involved or mechanically, and it was universally a good thing.

</comment><comment><USER33> Does anybody know some monorepo horror stories?

I have heard plenty of people complain about their many-repo structure and wishing for a monorepo. I would like to hear some concrete story where a monorepo went wrong. This article is just abstract opinion.

<comment><USER34> Oh yes. #1 problem I've experienced at multiple places: delaying integration with tons of branching.

Usually the PM or PO force everyones to using some vague "product version" they track for public releases. Places that use monorepos well tend to have very few branches (like, maybe 2 or 3), which have nothing to do with your public product versioning scheme, and instead use "branch by abstraction" to stay integrated.

But what I end up seeing, is that the product team and middle management gets involved with dictating version control, e.g., "this will be version 1.2, and then that should be 2.3, ok let's cut those branches...", and then they change their minds as some team has to delay and before another is ready. And then bugs start rolling in from both testing and they don't know what to do, and they start asking people to just "get it done", and then, things _really_ start falling apart. You add 10+ teams trying to use branches for their own work based off of god knows what and it becomes a mess of crazy integration problems.

I seriously think that a huge benefit of multiple repositories, is that is scares the pseudo-technical managers and product people into not bothering with trying to track or dictate usage of the version control system.

<comment><USER30> Or you could just tell them to stay off versioning/release/branching discussions, even in a monorepo. All they need to know is what release/deploy has what features, and when the release happens.

<comment><USER34> Easy to say when you're starting from scratch, but in all of my cases, these were "pre-existing conditions", i.e., was in place before I joined, and it took a long time to get people to see the light. It gets real tricky when you're _not_ a manager, and you're basically asking other managers to stop having such a loud voice in things.

Just another case of "culture eats strategy for breakfast". Once people start using any particular versioning strategy, it becomes canon, even if it's a terrible way to organize.

<comment><USER30> Yeah sorry if I came off as dismissive. It's usually a long process, if that's how things run.

</comment></comment></comment></comment></comment><comment><USER35> I think one should not underestimate the powers of the not-so-good-team to make anything go sour. Who says the not-so-good-team isn't going to make sure that any change needs to touch at least 3 repos and quite regularly as many as 10?

As for the philosophical issue that yosefk raises, I generally advocate solutions that work for the case that the team is good. I tend to think that if the team is not good you would be cooked anyway. Also, if you raise the stakes people might actually start learning a bit.

</comment><comment><USER36> > In a Good team, you don't have multiple concurrent branches from which > actual product deliveries are produced, and/or where most people get to > maintain these branches simultaneously for a long time.

These sorts of Black and White, naked assertions drive me nuts. Buried in this statement is an assumption that the only software model worth even discussing is SaaS software - all copies of the code being run are run by your team, so master@HEAD is our ground truth at all times (except during deployments, which BTW are happening at least 10 minutes out of every hour of every day...)

Teams that sell applications or allow self-hosting, or even some SaaS shops with large enough customers are going to have to maintain multiple release branches. Possibly for years. From personal experience, anything above 3 seems to become unsustainable. But having 3 repos (a monorepo with 2 active branches + master) may be the right answer for you. One can't work, and 100 is murder. Stop the pendulum in the middle.

</comment><comment><USER37> > If you agree with the above, the choice is up to your personal philosophy. > To me, for instance, it's a no-brainer

The most obvious issue with this post is it fails to acknowledge that for any production scale company, you can't blindly say that a decision like this is a choice of personal philosophy (unless you're starting a brand new project from scratch, in which case, spending tons of time structuring repos well probably isn't your first priority since new projects have very little code).

I'd love to see more articles that discuss repo structure in the context of a pre-existing codebase with hundreds of thousands of lines of production code and 10+ engineers collaborating on it.

For anyone reading: I'd be interested to hear anecdotes from people working at companies that have successfully (or unsuccessfully) re-structured a monorepo, the reasons you did it, how much time was invested in the restructure, and whether you think it was a net positive long-term.

</comment><comment><USER38> I think the whole idea of simplicity vs complexity, and the linked article "Worse is Better" is fundamentally ill-conceived. Simple vs. Complex is contextually relative. Literally every observer is subject to their own opinion of a design. Success in the wild = success. I think success in the wild, especially in our age of information overload, depends on being "convenient to understand and operate".

A 'simple' solution may not be easy to grok. Few people think at the level of axioms.

A survivable solution must be passed along to many people across generations.

For some, monorepos are simple because that is what they know, for others multirepos are the norm. The survival of the firms that adopt these strategies will somewhat dictate what repo strategy propagates in the world, not the best design.

</comment><comment><USER39> What author misses is that multi-repo is also not dumbass proof. Our team of about 60 people owned about 5-6 git repos that compiled into one SO. Every simple bug fix required multiple diffs to multiple repos.

The real argument that the author is making is that worse is better. Monorepo requires good tooling and a disciplined team. Multi-repo is worse but it is easier to manage when dealing with inexperienced programmers who want to have their own repo for their shiny little microservice.

IMO, the difference is that multi-repo has limitations and mono-repo has challenges. You will never get atomic commits and precise versioning in multi- repo. With mono-repo, there are a lot of challenges that can be solved with good engineering.

</comment><comment><USER40> Ask your doctor if Monorepo is right for you.

<comment><USER41> Individual results may vary. Don't take Monorepo if you are bad at programming, or if you may become bad at programming.

Side effects include but are not limited to your repo growing into a single giant ball of circular dependencies.

<comment><USER42> Monorepo may cause blindness, sleep deprivation and suicidal thoughts. If you experience any of these symptoms, stop taking monorepo and consult your manager.

<comment><USER43> If you experience a build lasting more than six hours, seek rockstar ninja help immediately.

</comment></comment></comment></comment><comment><USER44> Let's assume without proof that Glibc developers are good. Similarly, kernel.org developers are good as are the gcc.gnu.org people.

Should glibc, gcc and the kernel be in a monorepo?

(Cue laugh track ...)

<comment><USER45> Did you just invent the unikernel?

<comment><USER46> AFAIK, Unix did this, so BSD Unix did this, and the modern BSD derivatives still do this.

</comment></comment></comment><comment><USER47> One thing that's nice about a monorepo is if the language has modules. It it supports modules well you can isolate your code better but still keep it in one large repo.

I dislike having all my code under one 'src' directory and it's nice to have modules like foo-ui and foo-util and so forth. Knowing that one module doesn't use ui components is nice because you can use it on the backend for example.

But it's all fully integrated and tested together.

</comment><comment><USER45> Always makes me think of a philips radio my Dad told me about called the "Mono Knob". It had a complex design that allowed control via just one knob. He said they were always in the shop for repair when he worked as a teenager in a radio store.

[https://www.thevalvepage.com/radios/philips/785ax/785ax.htm](https://www.thevalvepage.com/radios/philips/785ax/785ax.htm)

</comment><comment><USER36> One of the tenets of XP that survived (or should I say, is amplified?) into CI/CD is the idea that you should build up callouses for painful activities instead of trying to avoid them.

In that context, if a thing is tough but has value, you make a path to it. First make the tools consistent, and then make people consistently use the tools. The more predictable the system becomes (predictability is the opposite of magic!), the more you insist on people using it. Pushback is a kind of feedback, and you have to address at least some of the concerns of people who refuse ('meet me halfway here').

Someday it will shock no-one to say that Git is not the best of all possible version control tools. If this is difficult, it may not be the people. Maybe it's time to start thinking about the next version control system?

SVN had some pretty decent facilities for monorepos. Some people will tell you that Git traded some of these features for others, but looking through the information architecture documentation for git, I don't think I can agree. Some of that information is there, it's just maybe not packaged for consumption.

</comment><comment><USER48> >bad fork

How is this an argument? You merge the unforked projects and its the equivalent to multirepo. I don't follow the argument at all.

...I started writing rebuttals to the others but I guess when your argument is "yeah you can do it right but you _could_ do it wrong and I have defined the question in such a way that we err on success for multi-repo and err on failure on mono-repo" I can't really fight that.

</comment><comment><USER49> You're just pushing your trouble into a shadow layer that's hidden. You still have just as much complexity. It's just not encoded.

If branch A on repo X will only work with branch B on repo Y, you're holding that relationship in an uncoded way. It's true and unrepresented, and you never want that.

</comment><comment><USER50> I've experienced 3 large codebases with different approaches:

1\. Monorepo: Google3

2\. Non monorepo, large pile of #@$: Microsoft Exchange

3\. Non monorepo, Amazon

After working with them, from my personal experience, monorepo was the best. Yes, Google has ton of internal stuff and they could go away with not using much of external dependencies, but when everything works, it works like a charm. Convenience of defining protobufs/contracts, ease of reference them and ton of the things are given to you when you're in the system.

At Google I never felt that the system is hostile to you. It was extremely easy to start hacking something if you'd like to. Yes, it's not only monorepo, but the overall quality of the tools available, but monorepo is also quite a significant part of it.

</comment><comment><USER51> > With multiple repos, modularity is the norm. (...) With a monorepo, > modularity is a mere ideal.

> ...

> In a not-so-good team, your monorepo will grow into a single giant ball of > circular dependencies.

Sounds like the author was lucky enough to not encounter a not-so-good team with multiple repos.... :D

</comment><comment><USER52> I'm firmly on team monorepo, and I agree great tooling is an absolute requirement. We use Bazel + AWS CodeBuild with local caching. We have an average incremental CI build of our monorepo that's under 45 seconds. Clean build 30+ minutes.

</comment><comment><USER53> There is also a way to simultaneously reap the drawbacks of monorepos and multirepos: consolidate numerous small repos into somewhat big monorepos and then don't merge everything into one big repo.

This way, you'll have to deal with

* difficult tooling

* dependency hell between the mono repos (which are now way more tightly coupled due to the dependency graph between them being denser)

* long living branches causing way more collateral damage as described in the original article

* cross-repo changes have become even harder for all the reasons above

You get all the bad things and avoid those advantages! Welcome to my world :)

</comment><comment><USER54> I feel like I'm missing something. Never used monorepo before but looking into it for our node code base. It seems like the combination of a monorepo and individually publishing the packages to a private npm server such as nexus eliminates many of these issues. One project can remain using an older version while another can use a breaking change. Pin your versions and follow semver and you should be fine. What am I missing here?

</comment><comment><USER55> Coming from a small company with a monorepo to a large team with a monorepo, it seems to work fine. But maybe I need to be exposed more to other workflows.

</comment><comment><USER56> My primary language now is Common Lisp and I have one mother of all mono repos for all of my personal Common Lisp code. I set the root of this repo as a Quicklisp load point so all my libraries and applications are available with a Quicklisp load. Life is good.

I don't quite get the point of this article though. I am a very enthusiastic but not rockstar programmer, and I don't have problems with a large mono repo.

<comment><USER57> But you're one person. The article argues that a single repo is unmanageable when you have _many_ devs working at the same time.

</comment></comment><comment><USER58> I find this article more compelling than Yossi's article: [http://blog.shippable.com/our-journey-to-microservices- and-a...](http://blog.shippable.com/our-journey-to-microservices-and-a-mono- repository)

Yossi's comes off extremely pretentious, without really explaining why people consider multi-repo projects to begin with.

</comment><comment><USER59> There's some nuggets of good things to look out for in here, but "don't do monorepo because your team is full of dumbasses" feels like a useless argument, maybe even a little adversarial. Monorepos solve versioning problems _very_ effectively, which would be a pro if you're worried about working with dumbasses.

</comment><comment><USER60> > like Google, the ultimate force for Good in technology

Hahaha...

[https://www.reddit.com/r/degoogle/](https://www.reddit.com/r/degoogle/)

[https://twitter.com/hashtag/degoogle](https://twitter.com/hashtag/degoogle)

</comment><comment><USER60> > What do you do when you have a branch working on Android and another branch > working on iOS and you have deliveries on both platforms?

Stop it and focus on one single web app instead that anyone can run. Unless your app is going to be in the top 10 that people can't miss downloading.

</comment><comment><USER61> Is being demeaning and rigid just the cool thing to do today in blogs. I feel like I keep reading articles like this every day now. "Well if your team is full of dumbasses" or "If you use OO instead of functional programming"

<comment><USER62> Have you not noticed that this is the new norm everywhere?

</comment></comment><comment><USER63> This reminds me of some the trade-offs I've looked at with monorepos: [https://epage.github.io/dev/monorepos/](https://epage.github.io/dev/monorepos/)

</comment><comment><USER64> So glad Yosef keeps writing on his blog. This is a well articulated gem. I had intuition as to why the monorepo style was not great for most shops. His clever argument nails it.

</comment><comment><USER65> Ugh I don't like his use of the word dumbass. Coding is hard, it's easy to break things. We've developed lots of tools of strategies so we don't have to rely on people getting it right every time.

Branching: getting forked by your worst programmer This example seems contrived I've never worked anywhere where having a fork that works for some scenarios and not others is tolerated for long. This would be given the highest priority.

Modularity: demoted from a norm to an ideal This is basically saying a multi- repo makes it hard to reuse your own code which increases modularity. I find devs on very large projects are already reticent to reuse code from other projects/teams, but this pushes them even farther to rewrite domain logic that should probably be shared. In most cases I'd trade a little bit of modularity for increased domain logic consistency.

Tooling: is yours better than the standard? There are few organizations that have so much code they break available source control solutions but simultaneously don't have the technical expertise to manage a monorepo that large. For these I guess it makes sense to break it up into manageable peaces based on the relationships between your projects.

I've worked on subpar teams that decided against monorepo and it was a nightmare. It took forever to get setup, the build time was days, and cross repo edits were painful. They regretted going multi-repo.

<comment><USER66> The branching example is very tempting when you have a product that is used on site by multiple customers. Customer A asks for some change that impacts customer B. Without good tests the easiest thing to do is fork the world for A and B, so the changes only impact one. Then you gradually drift apart. Add customer C, D, E... and it gets really fun.

With multiple repos it gets even crazier. You have forks for A and B that work with some other software repo, maybe common, maybe forked itself. Soon you have wiki pages with compatibility matrices, common libraries that mysteriously break with minor changes despite being battle tested ... for some set of versions.

<comment><USER67> Re:Branching, having lived this, monorepos are very much a blessing, not a curse.

If software is big enough to force considering monorepos, then cross-cutting dependencies will happen, and then one diffable long-lived monobranch is much better than a bunch of interleaved ones.

Incrementally building, landing, etc., cross-cutting deps becomes much less of a slog. Ex: skip concerns about versioning of _internal_ APIs.

The other issue I had was the sleight-of-hand on build modules. Yes, you don't need good devs to speed up incremental builds b/c you can search/build in each project. But if you want to run 20 modules together to test/experience them, good luck, esp. for interactive modes. (Congrats, you reinvented the monorepo!)</comment></comment></comment>


8 percent of Internet users account for 85 percent of all ad clicks - <AUTHOR> http://www.comscore.com/Press_Events/Press_Releases/2009/10/comScore_and_Starcom_USA_Release_Updated_Natural_Born_Clickers_Study_Showing_50_Percent_Drop_in_Number_of_U.S._Internet_Users_Who_Click_on_Display_Ads <comment><USER3> A misleading, but very viral headline that is going to misinform a lot of people about the state of online advertising . . .

Let's look at the data:

a) "The collaborative studies focus on an understanding of how U.S. Internet users click on display ads." - so we're talking about "display" not contextual, search, mobile, or any of the other high-engagement / high- relevancy ads that are among the highest-growth areas fueling online advertising's growth?

b) The inventory available for "display advertising" has SKYROCKETED - <USER2> 2007 to 2009 thanks to the popularity of social media sites which we all know has notoriously low CTRs. Facebook alone contributed hundreds of millions of users and showed them hundreds of billions (trillions? more?) of units of display advertising during that time period.

If you want the real goods on online advertising trends I reccomend you read the PWC IAB Advertising Revenue report:

<http://www.iab.net/insights_research/947883/adrevenuereport>

The data reflects a much more solid foundation for sustained growth in the online advertising marketplace than you may conclude from this link-bait from Comscore.

</comment><comment><USER4> One of the reasons I'm skeptical about advertising going forward (among several) is that as metrics get good enough, advertisers are going to want to stop paying for people like me who are minimally affected by ads. ("But you're affected subconsciously like everybody els..." Yes, thank you, I said _minimally_.) And we're not going to be randomly distributed. You might be able to make an ad-based business in bulk or on a band fan club site, but technical sites are going to be in a lot of trouble, I think. Can you imagine being kicked out of a site because you never click on ads? The tech is coming.

<comment><USER5> The only ads I can ever remember clicking on were accidental.

The only ads that really make sense, I think, are the branding/image/guiding type ads, not the performance-based CTR ads that have taken over the tubes.

Toyota did a whole damage control series during the purported uncontrolled acceleration debacle, and I noticed them and it influences your opinion. As do ads that build an image or general awareness: If I know about a brand of SSDs, maybe I'll search for that brand the next time I'm looking.

Ads that succeed or fail based upon a click have always been dumb. Remarkable that Google built a whole empire on it.

<comment><USER6> _One of the reasons I'm skeptical about advertising going forward (among several) is that as metrics get good enough, advertisers are going to want to stop paying for people like me who are minimally affected by ads._

Anecdote time..

 _Podcasts_ are still attracting plenty of advertisers, even with non- trackable generic ads, leading me to believe some advertisers don't care for tracking.

Check out Dan Benjamin's 5by5 family of podcasts - they're pretty much funded by advertising and most of it is poorly trackable. I don't know what he charges but from other similar podcasts I _do_ know the figures for I have reason to believe it's higher than $50 per 1000 listeners per show - this is astronomical compared to trackable forms of advertising online.

<comment><USER7> Television. Or Radio. Or Billboards. All better examples than podcasts.

<comment><USER6> I think cost of influence is a more important metric for judging how serious advertisers are than the overall size of a market.

Take television, for example:

 _"during the 2007-08 season, Grey's Anatomy was able to charge $419,000 per advertisement"_

Independently, I found the viewing figures were 17-18 million per episode for that season. So about $24.65 "CPM". And that was one of the best mainstream, regular ad returns on TV (CSI had a higher audience and far lower charges per ad). That's half of what I know even minor podcasts are making..

On the flip side, a TV show tends to have many ads packed in whereas a podcasts runs with a few at most but in terms of CPM, they seem to trump most TV.

<comment><USER7> fascinating. I wasn't aware of the ad rates for podcasts. Are they for american audiences or overall audiences? Because I would see Australian ads if I watches Grey's Anatomy or CSI -- but I hear the generic ads when I listen to TWIT.

My point was more that TV/etc is a fundamentally less trackable audience. (agreeing with your point that some advertisers don't require tackable ads).

</comment></comment></comment></comment></comment></comment><comment><USER8> This has been an open secret in the industry for years, since AOL released a rather disturbing report on "compulsive clickers".

Anecdotally, I theoretically could (but, as stated in my privacy policy, refuse to) identify a small handful of users from my site who get to it through "the best result" on the blue Googles _every single time_. (AdWords is profitable in aggregate so I've never given this issue serious thought with regards to assessing how much money it costs or whether it would be worthwhile to educate that population to save money.)

</comment><comment><USER9> Interesting.

Myself, I find that I click essentially two kinds of ads:

1) Sponsored search results that are exactly what I was looking for anyway, and

2) Ads relevant to my interests, typically delivered through the Fusion Ads network.

</comment><comment><USER10> Anybody that makes a substantial portion of their income on ads or plans to do so had better take notice.

The one good thing is that with performance based advertising it doesn't really matter who clicks the ad as long as there are sales it's a win for both parties. The inherent problem with performance based advertising is one of trust, do you trust party 'x' to truthfully report which sales were attributable to your ad inventory or not?

<comment><USER11> This is all fairly naive to be frank.

(I've made money from advertising since '99).

Ad revenue is increasing year on year. The sky isn't falling.

> "The inherent problem with performance based advertising"

Again, as someone who has made a lot of money from performance based advertising over the last 10 years, this isn't really an issue. You factor it into your ROI.

<comment><USER10> I think a 68% to 84% increase in the number of people that _never_ click ads is something to take note of.

For sure the number of 'clickers' will never reach 0 but this is definitely a trend worth monitoring.

<comment><USER11> Come on. You don't seriously believe those numbers do you? They're from crazyland.

Also there are so many types of advertising... Banner advertising is but one. Things go out of fashion, other types of advertising become popular, etc

I monitor my ad revenue and ROI _very_ closely, and have done over the last 10 years. Slightly more than some random unscientific 'study' ;)

<comment><USER10> <http://news.ycombinator.com/item?id=2101494>

<comment><USER11> lol What will that prove? Why not do a poll asking who here likes Justin Bieber?

</comment></comment></comment></comment></comment></comment><comment><USER12> I've never clicked a TV ad, direct mail flier, or billboard. That doesn't mean those ads are worthless. This is often a somewhat silly metric for measuring advertising depending upon the goals of that advertising.

Quote from the article: "Today, marketers who attempt to optimize their advertising campaigns solely around the click are assigning no value to the 84 percent of Internet users who don't click on an ad. That's precisely the wrong thing to do, because other comScore research has shown that non-clicked ads can also have a significant impact. As a result, savvy marketers are moving to an evaluation of the impact that all ad impressions – whether clicked or not – have on consumer behavior, mirroring the manner in which traditional advertising has been measured for decades using reach and frequency metrics."

</comment><comment><USER13> I used to think that I never click on ads, and it's true in that I never click on Internet ads, but I've found that ads I receive on Steam are vastly more effective for me.

If you don't know how Steam ads work, when you first log in to Steam, it will pop up a window with several pages of ads for different deals and promotions going on. Given how low some games on Steam cost, I find that I very frequently will click through and buy the games advertised (things like $5 for an otherwise $50 game can be so attractive!)

I guess the criteria I use for ads is relevance. The only thing I really ever buy over the internet is games, so advertising on the internet for anything that ISN'T a game just won't get my attention, no matter how well you write it.

</comment><comment><USER14> I think that for high volume customers with offline purchases, such as Tide who are essentially augmenting their traditional advertising with online this could be true. However, for low volume customers with online purchasing such as most startups it's probably best to stick to CTR.

Indeed, it would seem a new 'revelation' in online advertising that depreciates the value of a click would be highly valuable to web properties with notoriously low CTRs. I think it's primarily a puff piece to generate increase revenues for properties with low CTR. (I'm looking at you Facebook)

<comment><USER15> Google purports to do something similar on its display ad network - they call it "smart pricing". If it's a low quality placement that is "unlikely to produce an actionable business result" (their words), the CPC an advertiser pays is lowered below the natural auction price. The whole system is pretty opaque, but as you mentioned, it likely allows Google to keep millions of poorly performing pages in its display network without harming the overall network (too much.)

</comment></comment><comment><USER16> Advertising just makes more sense in some places than others. Google capitalizes on this because they have such a broad audience.

I also rarely click on ads, but one example where I always click search ads is - when I'm looking to hook up new Internet service. The best deals seem to inevitably be available from search ads on Google.

I think if the 8 percent making up the 85 percent of clicks are accidental, well...this will shake out eventually as advertisers try to optimize their spending. But it doesn't mean there won't be places where advertising is online is highly profitable.

</comment><comment><USER17> I think some of this has to do with proliferation of ad-blocking software (I hardly know anyone anymore who doesn't run AdBlocker Plus or an analog thereof), but perhaps even more to do with a more savvy audience.

Ads were once an avoidable consequence of watching TV. When I visit my parents, I have noted they have entirely altered the way they watch TV so that they can skip any and all ads with DVR. I can't help but think that active avoidance of ads in other mediums like this would perhaps lead way to passively avoiding ads (ignoring their presence) on the web.

</comment><comment><USER18> FYI this is referring only to display ads. Also, I'd take this with a grain of salt since the study itself states that view-through impacts are not to be ignored.

<comment><USER19> >> FYI this is referring only to display ads. Also, I'd take this with a grain of salt since the study itself states that view-through impacts are not to be ignored.

Actually, a different study than the one linked by the OP states this. A study they are careful not to elaborate upon in this press release. I worked for StarCom 1997-2000 in their new & shiny online advertising group. StarCom is heavily incented to produce research proving the effectiveness of all types of advertising. And they own a much larger share of online display advertising than they do of paid search engine marketing. I can't prove that their current research is biased. But when I worked there, we were quite careful to present our results in the best possible light. For example, we ran a very large banner ad campaign for a Proctor & Gamble product. There were two reasonable ways to determine if it was effective: Ask an online panel if the recalled seeing the banner ads in question. Or look at the actual grocery store / drug store sales data to see if the banner campaign caused any lift in sales. The first argued that the millions spent on this campaign produced OK brand awareness; the second demonstrated that it did nothing to move the product. Guess which of these two results went into our sales and marketing materials and which was omitted.

<comment><USER18> Glad to hear I'm not the only one who's skeptical. Not that I don't believe that view-through can't provide a measurable lift--I've just seen that the splitting the marketing budget between channels can get political. And attribution based on seemingly qualitative factors feels a bit hokey to me when you can really nail down ROI on a lot of the other marketing channels.

At any rate, I'm sure that P&G was happy :)

<comment><USER19> >> I've just seen that the splitting the marketing budget between channels can get political.

One of my favorite stories involved a very successful online marketing campaign for Oldsmobile. When they launched the Alero, there was amazing testing of TV vs. Print vs. Outdoor vs. Direct Mail vs. Online. They tested for scale - how many sales were produced - and cost per channel. The results were that Online came in #2, with print a distant third. Before the test, print had a $5mm spend and online was just shy of $1mm. After the test, Olds tried to move their entire print budget into online. The agency team at Leo Burnett (LB owned StarCom at the time) that was responsible for print hit the roof and waged a successful campaign to have much of their budget restored. They didn't want to lose their jobs, I guess.

</comment></comment></comment></comment><comment><USER20> On a related note, 8 percent of Internet users are somebody's grandmother.

</comment><comment> DanI-S I find this truly bizarre. Who are these 8%? Is there some new, widespread form of obsessive compulsive behaviour that involves clicking through EVERY link on EVERY page?

<comment><USER21> The thought process of non-technical people is truly fascinating. These are people who type "www.google.com" on Google, have 5+ toolbars and smiley screensavers installed, and generally act on any call to action that is presented to them (including fake antivirus warnings).

As web entrepreneurs we need to learn how to exploit these people and make as much money as possible from them. It's the right thing to do to preserve the natural selection process and ensure the proper evolution of the Homo Iunctus. /kidding

<comment><USER22> But in all seriousness, if you want to make a lot of money, it is in your interest to understand these people and make something that they want.

</comment></comment></comment><comment><USER23> One reason why nobody should get panicky about opt-in ad-block browser plugins draining ad revenue. Those people (me) were never going to click on your ads anyways.

</comment><comment><USER24> there has been some discussion about how google has incentive to lead people to spammy sites, because people click the adds. as people get better at the internet, spammy per-click adds become less profitable.

i speculate that advertisers are over-paying for per-click adds, and as that market settles, google will no longer have incentive to send people to spam pages, and make more money by sending people to legitimate sites with clean adds.

</comment><comment><USER25> Yes, they are mostly AOL members.

Not being funny, look at your user-agents for people who click on your ads.

As AOL dies, so does the ad clickers.

Don't worry, facebook will pick up the slack.

</comment><comment><USER26> Whoa, this press release was from October 2009. Got anything more recent than that?

</comment><comment><USER27> DId anyone else notice that the report is from 2009?

</comment><comment><USER28> Not only that, it's getting worse.</comment>


Ask HN: A founder with a criminal record - <AUTHOR>

I was reading an article, though I can not remember where, that said that Angel and VCs will pull out of a company where the founder has an undisclosed criminal record.
Is this the case for most VCs?  Is there any way to get around that?
If you are just honest, maybe not at first, but when you get to know the VC, do you think that would help?
In this case the conviction was when I was a teenager, though over 18, and it was a felony that involved theft.  I have since then, over 16 years, held many jobs that require trust, and have not done anything wrong at all. <comment><USER2> The age bracket is a dicey one, personally I wouldn't fret about it too much but I would definitely be the one to disclose it to my co-founders, no need to tell the world.

Typically getting to the state where you have contact with VCs and are fundable is the harder problem to solve, I doubt a 'name' VC would be overly worried about this unless it was something very recent and major, though it probably does not help any character assessment.

If there was doubt it will tend to reinforce that doubt, if there was no doubt then my guess is that it would be taken in stride. If you spent two years in jail that would be a different matter but the way you present it here it seems as though it was more of a slap-on-the-wrist style thing.

Play it down, plenty of people have done dumb stuff in their youth (I used to run a pirate radio station and built a whole bunch of transmitters for others for example, highly illegal at the time, but I never got caught) but make sure that if they're going to find out that they find out from you and not from a another party, and make sure that you realize that if you do not tell those the work with, depend on you and fund you that you're setting yourself up for blackmail.

<comment><AUTHOR> My co-founder is my best friend and someone I consider a little brother. He knows, and has known for as long as I have known him.

</comment></comment><comment><USER3> I'm in a similar boat as you although not quite as far removed from the conviction/s. It can be very tough at times, because my record is going to follow me for the rest of my life. I've changed completely and lived on the right side of the law for years but I continue to lose work from time to time due to my record.

In general, I don't bring it up to people but when I'm questioned about it, I always answer honestly. I can be trusted. A some of my friends have laughed at one time or another about stealing supplies from their company or how much they slack off. I will probably always be a better employee then them and they will probably always have a lot easier time finding jobs.

I was lucky enough to have my felony expunged and the rest of the incidents don't look good but are far easier to explain. I'd look into getting your felony expunged, here's some new info you may not have seen:

Gay v. Ariail ([http://www.judicial.state.sc.us/opinions/displayOpinion.cfm?...](http://www.judicial.state.sc.us/opinions/displayOpinion.cfm?caseNo=26592)) in 2009 decided that a person could have their record expunged after 15 years pursuant to SC's Youthful Offender Act even if the person was not sentenced under YOA provisions. You mention being a teenager but over 18, so I'm assuming 18 or 19. A youthful offender is defined as someone between 17 and 25. It also needs to be 15 years before you can expunge the record (you've stated 16). The other part of the puzzle is that your conviction can not be a violent crime. You mention a felony theft, so hopefully that's just due to $ amount. SC's definition of violent crimes can be found at <http://www.scstatehouse.gov/code/t16c001.htm> (Section 16-1-60).

If you want to talk to someone (albeit younger) who's dealt with a lot of similar situations, let me know and we can find a way to communicate.

Best of luck either way. It sounds like you changed your life around and deserve to be trusted today.

Loophole / Possible Alternative: Quit, don't be a founder, be a well- compensated first employee or something similar.

</comment><comment><USER4> Lets face it, it's not a point in your favor. But the good news is that trust can be earned. I trust people I've worked with who have pulled 20 hour days with me or who I've climbed mountains with and who have held the rope my life depends on. So put yourself in positions where you are exposed to investors and where you have an opportunity to earn their trust.

I would also take the strategy of being very very open about this. Post a blog entry that says: My name is Mike Jones, I have a criminal record, I'm creating a startup that does XYZ.

You could even capitalize on it: Create a startup that is a job board for ex cons. Or a forum where people with records in their distant pasts can share notes and advice on how to work around it.

</comment><comment><USER5> Have you looked into the possibility of having it expunged?

<comment><AUTHOR> The state in question, SC, doesn't allow felonies to be expunged. I have thought about hiring a lawyer and tossing money at the problem, but since I live in CA normal background checks don't return anything, but extensive ones do.

</comment></comment><comment><USER6> I've got a felony conviction from over 22 years ago, and for contract hunting, I actually turn this into an advantage. For instance, I "advertise" as already having a clean background check going back 15-20 years. For your situation, just be up-front with your co-founders (which I read you have), and perhaps stay out of any function that involves finances.

</comment><comment><USER7> I'd think the key word there is "undisclosed". If they're going to find out, they had better find out from you.

<comment><AUTHOR> I agree, and I would definitely bring it to their attention AFTER we got our foot in the door, but way before funding.

</comment></comment><comment><USER8> If after disclosing the felony conviction you can discuss it intelligently, I doubt it would be a deal breaker. Although someone might use it as an excuse to back away, I doubt that a conviction half a lifetime ago would be the main reason. Particularly if you are part of a strong team.

<comment><AUTHOR> Thank you, that makes me feel better.

</comment></comment><comment><USER9> I just got a DUI. I don't need a VC, but if a VC were to reject me b/c of this I'd find another one. I don't think you can win if the other party has such a limiting belief.

<comment><USER10> I don't think that not wanting to invest in someone who has recently shown a complete failure in judgment is much of a limiting belief. If you can't take other people's lives seriously, how can you be expected to take other people's money seriously? If the DUI were a little further in the past then it would be a different story, and I'm sure there are VCs out there wouldn't care about a recent one, but if I were a VC I'd move on pretty quickly.

<comment><USER9> Oh, please:) Tell me overwhelming majority never operated an internal combustion engine under influence. I didn't say I don't take other people's lives seriously. I said I got caught. Now, holding a belief that this somehow causes a reduction in my performance to create something that humans like, is indeed a limiting belief. Forget about causality, one would be hard pressed to display co-existence in that domain. I would expect the co-existence to point to the inverse: increased intoxicating chemical consumption co-exists with increased creativity (probably, mainly because pure creativity is not exactly human).</comment></comment></comment>