
I could do that in a weekend (2016) - spiffytech
https://danluu.com/sounds-easy/
======
michaelbuckbee
To OP's point of "features are more complicated than they appear" I always
like to point to the flowchart of Slack's notification logic.

[https://pbs.twimg.com/media/C6ROe0mU0AEmpzz?format=jpg](https://pbs.twimg.com/media/C6ROe0mU0AEmpzz?format=jpg)

~~~
saagarjha
This was actually less complicated that I had expected it to be.

~~~
evfanknitram
Yes, this is what my co-workers refer to as an if-statement.

~~~
paxys
All programming is just if statements. That doesn't mean systems can't be
complex.

~~~
a1369209993
Not true; if the conditional branch goes backward then it's a (possibly do-)
while statement. Also subroutine calls.

~~~
seisvelas
Counternitpick: Those subrouting calls and while statements are compiled to
conditional jmps. If you squint your eyes it's just a fancy 'if'.

~~~
zimpenfish
"It's no use, @a1369209993 - it's IF statements all the way down!"

Apologies to William James' apocryphal quote.

------
kstrauser
I wholeheartedly agree, to a point. Sometimes hideously complex things look so
easy because really smart people came up with a particularly elegant solution,
so any rando off the street sees it and figures they could reproduce the
thing.

However, I worked for a company who had a whole team of engineers and QA
people working for months on what was basically a Django CMS, but with a large
dose of "not invented here"-driven writing of everything from scratch. I'd
finally gotten tired of it, so I spent a weekend at home implementing it in
Django and being done with it.

I did learn two very important lessons, though:

\- The other stakeholders _really_ did not like someone demonstrating a
working prototype of something they'd been doing unsuccessfully for months,
and I got a thorough chewing out for disrupting their processes.

\- I really didn't want to work for such an organization, and was much happier
after moving to a smaller, more nimble company.

~~~
munchbunny
From my experience, when I'm working on real world problems of nontrivial
sizes and I see a big chunk of well organized, like a really well organized
service, almost always it's because that was the latest cleanup/refactoring
effort that happened after many years when the problem space was a moving
target, and finally it stopped changing long enough to come up with a clean
abstraction.

The cleanest code I've ever written has always been on the second or third
try. Write it once, test it against the real world, then rewrite it to take
the new discoveries into account. It's too bad we rarely have the luxury of
breathing room to rewrite things.

~~~
kstrauser
I wholeheartedly agree. This was a brand new project, though.

~~~
munchbunny
Indeed, upon reread I think I responded to what I thought you said, not what
you actually said.

Anecdotally, "not invented here" is consistently the most egregious source of
unneeded complexity I've seen in my career.

------
ascendantlogic
There's always two things that these armchair quarterback software devs seem
to miss: Scale and Money.

Sure you can hack together a small Google clone using Elasticsearch in a
weekend. Can you index all the worlds information and serve the worlds search
needs with your little MVP? 99.99% chance no, even if you were given a few
hundred engineers to scale it.

Even if you could do it technically, where are you coming up with the money to
do so? That's not seed-round or even series A round money to do that. That's
series D, hundred+ million dollar swipes of a VC's credit card just to get off
the ground. Microsoft threw billions at it with Bing and still never became
more than an also-ran. The only place that seems to have a real chance is
DuckDuckGo, and I'd be very interested to see how their story has played out
up to this point.

Google benefited greatly from growing as the web was growing. Trying to index
the world's information in 2020 is an astronomical task compared to indexing
the world's information in 98, 99 era.

~~~
mettamage
> Scale and Money

This is too simple of an answer. By these metrics Google+ would be a success.
Also, the total funding amound of DDG is 13M (see Crunchbase). While that is
serious money, that's not series D money.

Moreover, there are counterexamples of companies that did build an app in a
relatively short amount of time, kept a small team and made millions per
employee. I don't know of many [1], but I think WuFoo is an interesting
example, founded in 2006 while SurveyMonkey was founded in 1999. WuFoo exited
for 35 million in 2011 with a team of 9, I think (there's a YC YouTube video
about this somewhere).

Disclaimer: I'm an armchair quarterback.

[1] I don't know of many tech companies in general.

~~~
drevil-v2
WhatsApp is another example. I believe it was 13(?) employees, $16 billion
exit and close to a billion users worldwide

~~~
mettamage
Yea, also pretty small scale-wise, from what I've heard.

------
gustavo-fring
There is a lazy argument that ignores the difficulty and hard work of putting
out not only a working but a good application out, but the other end of that
is using Dan's argument (which is valid), to dismiss criticism.

To wit, Google has 80k employees now, in 2010 it was at 10k and the number
only drops as you go further back. I think it's pretty easy to say that Google
was doing more impressive things at the beginning of the century, and
certainly the climb was greater. Within the last five years, there was a
moment when Google had 4 competing chat apps. This is pretty rank
inefficiency. If you were to take 80k people (not all are engineers,
obviously) and sit them down and ask them to use their talents to build
separately, you'd end up with a lot more innovation and productivity, I'm
pretty certain of that.

The entire point of a minimum viable product is not that you have a complete,
flawless app, but rather that you get something up you can iterate on quickly.
That can be built in a weekend (I'm a slow worker, but I know people that can
do crazy stuff in a night and interest). My personal criticism (and something
I'm testing), is that our current processes are not harnessing all the gains
in productivity we've seen over the decades, nor the ability to do that
because it is very cheap to do so is not happening on a large scale. It's not
totally apparent why it is happening, but it isn't.

I realized late that people take this criticism personally and feel like
you're saying they are stupid or don't work hard or it is all so easy, but I
ask you to consider the nature of our industry and how easy things are to
build and then ask you why we don't see real competition across so many
products.

The moats of many companies are perceived. The goal isn't to build Google in a
weekend, it's to take the first step and give yourself an opportunity.

edit: my numbers are off, it's 25k to 100k

~~~
crazygringo
> _I think it 's pretty easy to say that Google was doing more impressive
> things at the beginning of the century... Within the last five years, there
> was a moment when Google had 4 competing chat apps. This is pretty rank
> inefficiency. If you were to take 80k people (not all are engineers,
> obviously) and sit them down and ask them to use their talents to build
> separately, you'd end up with a lot more innovation and productivity, I'm
> pretty certain of that._

You're misunderstanding how large companies operate.

Their job is not to produce massive innovation -- that's what startups are
mostly for, because most innovation actually fails in the market. Once
innovation is proven, a big company like Google or Facebook can buy it to
scale it larger and with less risk than the startup could have on their own.

Google's job has been to increase revenue, and they've been doing a great job
at that. The productivity increase happens from building enterprise features,
hiring gigantic sales teams, etc. Building Google Cloud.

And separate chat apps is necessary when WhatsApp and Slack and iMessage are
eating your lunch. You can't risk having a single chat app that fails -- so
you build one (Duo) that competes with WhatsApp and iMessage, another
(Hangouts Chat) that competes with Slack, without pulling the plug (yet) on
the legacy Hangouts.

So if you took all 80k people, as you suggest, you'd wind up with a mess of
startups which will mostly fail. You're not going to wind up with Google's
actual increases in revenues, that's for sure.

~~~
gustavo-fring
I understand that's how lots of big companies operate, but I disagree that's
how companies have to or should operate. The 80k thing isn't he notion that
you'd get 80k success stories (you won't), but rather that if you had a .01%
success rate, you'd still end up with 8 successful companies out of that, and
the market is big enough for those 8 companies doing different things, making
lots of money, and creating jobs/value. But more importantly, I feel like it
would be better for us as societies.

~~~
jmchuster
Google Ventures already spends $4.5 billion on that very thing? And there are
tons of other VCs and incubators out there?

------
saagarjha
I'm obligated to post a reminder that sometimes your team _is_ horribly
bloated or incompetent or your choice of technology is wrong, so make sure
you're actually doing useful things before feeling relieved that you're
invincible. Sure, nobody is going to upend your business in a weekend, but
there's been many, many examples of a company doing this and then someone
working by themselves for a couple of months or years (usually, this is just
someone who actually bothered to care enough to spend time on the problem)
comes along and does far more than they thought was possible. Stay on your
toes!

------
6gvONxR4sf7o
I wonder about this as an efficiency thing. Instead of search, let's use a
charity as an example. Why does XYZ charity need a zillion people? Why does it
spend so much on TV ads? The answer tends to be that hiring more people and
advertising more brings in more net dollars. You add and add until the
marginal cost of another ad/hire/whatever matches the marginal gain. It makes
total sense for the charity to do this, but as a potential donor, now less of
your dollars go to the thing you care about and more go to admin, advertisers,
etc. It's like friction in the system. To compete with you, now other people
have to spend on ads, and the whole ecosystem is less efficient.

I think there's an analogy here for for profit companies. Maybe if instead of
adding a tiny marginal dollar for BigCo, you could add a big marginal dollar
for SmallCo, and society's per capita productivity is lower? I can't pinpoint
whether the analogy works for companies, but I suspect it does.

------
valachio
The author's website is an example of a product that is "done in a weekend".

It is very annoying to this post on a 28" monitor... the text runs from left
to right with no margin spacing.

~~~
dmart
A certain set of people take enormous pride in using unstyled HTML like this.
(See "Motherfucking Website" [0])

The problem is it's not 1994 anymore, monitors are no longer 800 pixels wide,
so it looks like shit and is impossible to read. It's well accepted that
70-90ish characters per line is best for readability, and instead now on an
average monitor unstyled HTML gives you like 250.

[0] [https://motherfuckingwebsite.com/](https://motherfuckingwebsite.com/)

~~~
oxalorg
I solve this problem using a bookmarklet [0] which automagically applies sane
css to websites like these.

It’s insane that it’s 2020 and some people still refuse to use CSS haha

[0]:
[https://oxal.org/projects/sakura/bookmark](https://oxal.org/projects/sakura/bookmark)

~~~
zokier
What is insane is that peoples user-agents do not format documents the way
their users want.

~~~
flukus
They're getting better with reader modes, I just which they could remember
what pages were in reader mode and be less picky about when it's available.
Some default syntax highlighting would be nice too.

------
dudul
So yes. I'm a big fan of avoiding the hand waving and garbage like that when
describing/specing a product's behavior. Features are always more complicated
than the elevator pitch, there are edge cases, points of integration with the
rest of the system, etc. So yes, things are almost always more complex than
they appear.

But also, no, I've definitely seen a lot of companies with an insane headcount
simply to "do more in parallel" or "deal with the complexity of the system".
Sometimes, having too many people to keep busy is really bad.

------
yingw787
God. I remember reading this a year ago.

I've been working on TinyDev for about...two months longer than I thought I
would have, and I still have probably a month left to go before it's
completely ready. Just the amount of ops work you need to do in order to lock
down your stack is absolutely insane. That's assuming you invest in ops work
in the first place, which many places don't, hence technical debt and war
rooms and fires and the slowness of project management resulting in massive
backlogs and the like.

I'm going to do a writeup hopefully up this weekend on backend level to VPC
level work, just so that I can lock in my learnings. What I can say now is,
the only easy day was yesterday.

------
cwackerfuss
A little line-height and content max-width could go a long way

~~~
scott_s
Because the content is just simple HTML, it's amenable to the reader view
option available in most browsers.

~~~
benhurmarcel
You can put some simple CSS and still leave the simple HTML available to be
styled by the browser's reader mode.

~~~
hombre_fatal
You're never going to please everyone. I've seen HNers complain about the
opposite, that they have a large monitor for a reason and the web designer has
wronged them by adding margins.

Anyways, I think we're all big boys and girls who can figure out how to use
reader mode or resize a window in 2020. That's the whole beauty of the web
browser.

------
code4tee
I like the post but it does somewhat miss the point of these comments when
they’re made. It’s not usually someone saying they could rebuild the whole
site / product / company in a weekend but rather challenging the value that
everything beyond MVP is adding and all the staff that go into supporting
everything beyond MVP.

Companies tend to vastly over-complicate things and to support that end up
having ever growing teams to support the ever growing over-complexity and
feature bloat.

I can’t tell you the number of times a team has said it takes so long to
deliver something with 3x the number of engineers because they need more
testing, backend and such but meanwhile the core product features that
customers care about are delayed and not materializing. It’s not that these
other things don’t matter but all the “other stuff” shouldn’t take priority
over having a lean and mean product that works and people use.

Thus it’s less “why does this company have 100 engineers” and more “why does
this company not just exist as a far simpler and leaner product?”

~~~
ineedasername
_> “why does this company not just exist as a far simpler and leaner
product?”_

I'm sure there are bloated teams, but apart from those the argument against a
very lean product is growth of the consumer base. You make a lean product, get
some users. They love it. You do a little research into customer churn though,
or followup on marketing efforts to people that didn't yield, and find out
that feature X is a common thread: you don't have feature X. So you build
feature X. You gain incremental customer & revenue growth as a result. Then
the process begins again. The problem is that at some point you reach a point
of diminishing returns, and if you don't recognize that point, you'll still go
over the bloat line.

------
pandesal
Great read. HN and reddit comments like the post title always irks me whenever
a product is talked about in here or in reddit.

~~~
MattGaiser
I would find it hilarious to throw a QA team at one of those weekend builds.

~~~
starpilot
Hey, now. I built a PHP CMS for my friend's university club website 12 years
ago in a weekend. It had user accounts, profiles, user posts. That's pretty
much proto-Facebook, right? I could just scale that up to a billion users,
right? /s

------
twhb
To make this website readable in Chrome, load the page, type “javascript:”
into the URL bar (it can’t be copy-pasted there), paste the following
paragraph after that text, hit enter.

document.body.style.cssText = 'max-width: 35em; margin: 0 auto; padding:
1.5em; line-height: 1.4;'; 0;

In Safari, Firefox, and Edge, I recommend just using reader mode.

------
Silhouette
Someone with considerable but realistic skill _could_ build a passable
approximation of a lot of successful web apps in a weekend, and a very small
team of good people could probably build a production-ready version in a
month.

It's the other 95% of what the original business did to become successful that
usually gets overlooked.

------
renewiltord
The community solved this generations ago with one phrase: "Talk is cheap.
Show me the code."

I guess now that we know it's more than just the program, the startup adage
equivalent is "Talk is cheap. Show me the product."

------
empath75
Most of the big sites _were_ built by a couple of coders in a few weekends.
Google was online a few months after the page rank paper was published.
Twitter took a small team a couple of months for the initial release.
Zuckerberg famously wrote facebook in a couple of weekends.

Most of the explosive growth of those companies was built on essentially
weekend projects by a handful of coders, or even one person.

You absolutely can write a billion dollar app in a weekend. If you have the
right idea at the right time, with the right connections.

~~~
opportune
The entire point of the article is that the long tail of things to do grossly
outweighs the happy-path MVP...

------
jgwil2
Should be marked "(2016)"

------
hyperpallium
About _non-algorithm_ competitive advantages. It's easy to switch search
engines, so google invests madly:

Capital - massive capital investment in data centre around the world, for low
latency, particularly for Google Suggest. Capital is an enormous barrier-to-
entry for web startups. Google made search capital-intensive.

PR - consumer habit, supported by those myriad projects that position google
in consumer minds as "leading tech company". It matters that you are the best;
it matters that decision makers know you are the best.

Data - being first gives you a headstart, but competitors will catch up if you
don't run at least as fast (and ways to improve that consumers care about -
more running track). If you can something you have to do this that competitors
lack, it's easier. So google madly collects data, and uses it to e.g. NLP of
queries

Backend - Sergy did a lot with little hardware in the beginning, and that has
continued, I believe including their own silicon.

All that gives google time to rival better search - and money buy it.

------
pierremenard
The article seems to argue that

1) there is no viable search competitor to Google, therefore

2) search must be a much harder problem that takes more engineers than we
expect, therefore

3) it's hard to reproduce Google's success because you can't actually do what
10^n engineers do in a weekend.

I think that's plausible, but it needs to be emphasized that search could very
well be not that hard, but no one has overtaken Google because they have
inferior marketing, distribution, present too high of a switching cost, etc.

Just because Google has a bunch of engineers solving that problem (and
reproducing what Google does seems complex for correct reasons pointed out in
the article) doesn't mean that the engineers are actually adding that much
marginal value. My guess is that even if Google invested less in search
engineering, and didn't solve real time indexing and some other edge cases
this well, it would still be leading the field.

~~~
biggestdecision
Part of the challenge of competing, is that it's so easy for Google to adopt
good features from other search engines.

I'm not sure what to call these, but you know the rich results Google searches
provide these days? Like showing the definition of a word, or a snippet of
data from Wikipedia off to the side of the main search results. It's a useful
feature, and it was first developed by DuckDuckGo not Google. But it didn't
matter, because it was so easy for Google to adopt a feature like that into
their own product.

------
JackFr
I was in a meeting where someone from the business side complained that we
were taking too long developing the feature and said “I wrote the same thing
at my last company and I did it in one night while watching TV.”

My boss paused for a minute and then asked “What were you watching?”

------
grandridge
Except when Uber and Lyft were kicked out of Austin, ride austin was up in a
matter of weeks

~~~
steveklabnik
Ride Austin is wonderful, but does not do the same thing that Uber and Lyft
do. Namely: they're only in Austin.

Additionally, from their own site:
[http://www.rideaustin.com/faq](http://www.rideaustin.com/faq)

> How much has it cost to build RideAustin?

> The tech community contributed technology to power the app that costs
> millions to develop - but it also took over $7 million in cash donations and
> significant in-kind services donations to make RideAustin what it is today.

That is non-trivial.

------
titzer
It's all fun and games until it's time to scale, which comes with the need for
monitoring, versioning, scaled rollouts/rollbacks, DoS protection, replication
and distribution, and the long tail of bugs.

------
forrestthewoods
[https://en.wikipedia.org/wiki/Coastline_paradox](https://en.wikipedia.org/wiki/Coastline_paradox)

The devil is always in the details.

------
eloff
I was recently reminded of this while reading posts on hn wondering why Lyft
and Uber have thousands of engineers and what do they do all day.

I wonder if this was reposted here for the same reason.

------
bluedino
People make the mistake of saying "I could build GMail in a weekend!", when
they really mean, "I could build _a web-based email system_ in a weekend."

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=12626314](https://news.ycombinator.com/item?id=12626314)

------
lordnacho
"except that when you talk to companies that handle their own billing, they
can point to individual features that increase conversion by single or double
digit percentages that they can't get from Stripe or Braintree"

Kinda intrigued as to what that means? What features in the billing increase
conversion by percentage points, but are not available via an outsourced
payment provider like Stripe?

~~~
heavenlyblue
They lose customer data and then end up in newspapers.

------
pazimzadeh
Except that Google didn't become #1 by having better support for Arabic and
Japanese than Yahoo/Lycos/Dogpile.

------
CarVac
I never have this problem because it always takes me solid weeks to properly
design and implement a single new feature in my photo editor's user interface.
Sure, I could slap something shitty together in a weekend, but then you have a
shitty UI and people complain about open-source software UI enough already.

------
crnkofe
I've heard plenty of comments like that. People often trivialize things they
don't understand. As a developer I tend to focus on that one feature I know
how to build and ignore the rest.

Or in other words - it's easy to bake a bread loaf but running a bakery is
much more complicated.

------
Pxtl
This article would be better if be didn't use Google indexing Twitter as an
example, since I can never ever find tweets I remember on Google.

------
freepor
The other is "why so many employees." As if one guy writes Salesforce in a
weekend and then that's all there is to it.

------
ineedasername
I could have written this blog post in a weekend.

(I know, downvotes incoming. Worth it)

------
bjornsing
It’s not trivial to build google.com? No shit, Sherlock.

------
scoot_718
Except I actually could build StackOverflow in a day. Less than that actually,
just need some fiber and coffee.

------
encoderer
There is a simple recipe:

1 part arrogance.

1 part optimism.

1 part naïveté.

Do not over mix. Bake half way.

------
buboard
This is overly simplistic. There is plenty of great services that can be done
in a weekend. And some very elaborate engineering projects with tiny traffic.
When people wonder "why they need so many programmers", sometimes they are
right. They hired them to stop them from building competitors.

~~~
chillacy
> They hired them to stop them from building competitors

If that were true, wouldn't you have to hire every developer who could
possibly build your app in a weekend to succeed at that? It just takes one to
start a new competitor.

Building a new competitor is more than just a matter of code, there are often
network effects, a lot of marketing, and often still a cost to switch from a
less than optimal but good enough solution to an optimal one.

~~~
Rury
You're not wrong, but neither is the OP. Sometimes big companies simply buy
out startups so they can maintain market dominance - whether they be direct
competitors or new emerging markets.

You see this with Facebook buying Oculus in 2014, Microsoft buying Skype in
2008, Google buying Waze in 2013, Apple buying Shazam etc.

Also this is not privy to the tech industry. Large companies of all sorts of
industries use the growth by acquisition strategy.

------
amelius
> But in the comments on Alex's posts, multiple people respond and say that
> Lucene basically does the same thing Google does and that Lucene is poised
> to surpass Google's capabilities in the next few years.

Let's first build a benchmark. Without it, you're basically in the dark.

~~~
gipp
Well that's just reinforcing their point. Do you have any idea how much Google
spends on creating some semblance of "search quality benchmarking" that
actually means something? I'd venture it's way, way more than you imagine.

