I could do that in a weekend (2016) | Hacker News Reader

I could do that in a weekend (2016)

danluu.com

338 pointsspiffytech195 comments

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

This is a luxury if you as a dev get handed something like this. If you're actually the one that has to make the flowchart by translating customer requests, it's clearly a lot harder.

All hail the product people that have to do this.

In my experience, virtually none of the product people do this, at least initially. The requirement to begin with covers about 10% of this flowchart, then engineers start asking questions about edge cases, and pretty soon you’re sitting through your third meeting trying to just get everyone on the same page of what the requirements are, let alone how to build it.

You missed the part where you ship it with the 10% covered and then those "edge cases" get reported by pissed off customers who keep getting alerted despite their notification preferences.

Not to mention these notifications cross multiple devices so depending on how the teams are split there might be totally different teams managing the frontend toggles to change them and the backend services that persist those toggles... and then maybe a team or two to actually handle the sending.

Maybe another team that's just dealing with the WebSockets - gotta get notified about new messages if you have the app open, too.

Same here. I guess this is the ethos of Agile? Start somewhere and iterate on requirements/edge cases as they're needed/arise?

Though I kind of hate this approach. As when you begin with just 10% and keep tacking on things for edge cases, you tend to get a crummier solution in the end than you otherwise would have. But that's why refactoring is a thing right? Oh wait, management is against that because they don't acknowledge technical debt...

Let me just slip this in here: https://www.youtube.com/watch?v=P4VBqTViEx4

I like this one from ChromeOS about boot decisions.

https://www.chromium.org/_/rsrc/1277241373652/chromium-os/ch...

Somewhat related: in spite of this complexity, Slack desktop is missing options in closely related functionality. The only way to avoid a visible badge appearing on a slack workspace is to sign out entirely, which lands you in the tire fire of trying to reauthenticate to a slack.

So you can silence notifications, but unless you're good at ignoring those little red dots, you'll still be distracted.

That Slack chart is horrifying because unlike most cases of "features are more complicated than they appear", everything in this chart is user-facing. No Slack user is going to be able to follow all of this to know for sure how exactly their notifications get filtered.

I agree with you. I’m actually quite excited to see that chart, because now I might be able to figure out why I often don’t get messages sent to my phone, but the show as unread when I get back to the computer...

If you're still "active" on the computer it notifies you there and doesn't think it needs to also reach you on mobile. But I think you can set your mobile notifications to notify anyway.

Discord is nice with this and if your desktop goes idle without you reading messages it then pushes them to your phone. It’s one of the best features I haven’t seen in many other products. Particularly as it mutes your mobile notifications when you are on desktop. Which a lot of products also get wrong.

I think the elegance is that all of this logic boils down to a few user inputs (global + channel notification prefs) and overall everything ends up feeling pretty intuitive.

That’s just my opinion as a Slack user but as someone who’s worked on notification and badge systems I appreciate the honing that’s been done here.

It's convoluted because it's expressed in an incomprehensible way. Make it a Petri net or something, first decide what is the class of the message & pref of that class and it's 3x simpler.

And still people use @here or @channel without good reason. Every time I see this I'm reminded that social problems don't have technical solutions, not that that the technical solution was clever.

So is it a solution to a problem or is it just papering over a completely different problem?

Nice. The fact that it can be described by a diagram that fits on a single screen and could be absorbed by a new hire in 20 minutes is neat.

I wonder if there are ways to design software such that we can get visualizations like this generated from the code "for free". It could definitely be really useful when diff'ing code, or even just for general communication in meetings etc...

Perhaps there are some academic/esoteric languages that do things along those lines?

Did a quick search and found code2flow. Seems to be a cloud tool, where I have to upload my code.

I'm more interested in an open source tool, that can run locally with TypeScript.

Anyone knows a tool/package?

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

I think the example still works because, while it is not too complicated to understand, it is also non-trivial. It's also probably more complicated than the typical non-technical person would think.

It's also worth mentioning that this diagram doesn't capture dataflow or the relationships between the subsystems needed to make this work. The logic for notifications requires interaction with user preferences, channel membership, comment parsing, thread management, and more[0].

All told, you may still be looking at (low) thousands of lines of code, with maybe 1.5-2x times that amount for test code.

[0] I'm just guessing how the app is structured internally. I have no idea what it is actually like.

It's also like 3 years old. Would love to see what it looks like now.

It's like never true, it does not show that you can't get email notification faster than in 30 minutes.

Also now should include adding random old stuff to notification.

Things like notifications have pressure on them to be simple, because users want to be able to decide when they will receive notifications, which means it needs to be easy for them to understand when they will and will not receive them with particular settings. I'm sure there are examples of some non-user-controlled decisions that have much more complicated flow charts.

Yes, it was something I'd never thought of before, but definitely simpler than I guessed before I clicked the link. That said, each time you add a conditional, you need to be increasingly careful about where you put it, and what other impacts it has.

I would also imagine that there are a variety of other features which require similar flow charts.

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

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

If you're creative you can get away without conditional branches: http://www.jucs.org/jucs_2_11/conditional_branching_is_not/R...

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

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

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

Apologies to William James' apocryphal quote.

This is not about how it translates into code. I see a lot of value in this diagram when compared to the half-assed "requirements" most PMs put in their JIRA tickets.

That is my takeaway: PMs and non-developers - you must think through the entire workflow. When you don't, your engineers will and will either pepper you with questions that you are not prepared for or they will decide for you.

As an engineer, I consider fleshing out incomplete workflows to be one of the largest parts of my job. I've found the technique of saying "hey, the specification doesn't mention what to do in this situation, based on X/Y/Z elsewhere in the specification / this other similar feature, I'm operating under the assumption that it should work like <description of your best guess>. Let me know if that's mistaken". Then I make sure I have a commit of the state of the code, and start building based on the stated assumption.

A large fraction of the time, the PM just goes "that is correct", and the spec / ticket / whatever gets updated. When the answer is not "that is correct", you do lose out on whatever work you've done since sending that message, but writing code you eventually throw away isn't the end of the world. Also "that is not correct" responses often highlight areas where either the developer misunderstood what the PM was envisioning or the PM has a misunderstanding of what the system can do or how their proposed feature interacts with something else.

For this to work, you need:

1. Some variety of asynchronous channel that the developer can push stuff into at whatever frequency they want, and that the PM periodically catches up on entirely.

2. The developer to have a working understanding of how existing systems work and the system as a whole, from the business level.

3. The flexibility to modify specifications between the initial conception and implementation.

If you have all of those things, the PM doesn't necessarily need to think through the entire workflow beforehand -- it's nice if they can do that, but you can still ship working features without that and sometimes that is the pragmatic way to do it.

I'm exactly on the same page, this is uncanny!

If you've thought about the entire workflow, all edge cases and the spec is 100% complete then you've written code, it's just a matter of whether humans or machines will compile it.

I find myself creating a lot of these diagrams to share with PMs (along with sequence diagrams, system architecture diagrams, decision tables, etc.).

Systematically articulating all of these different conditions isn't necessarily the strong suit of a PM, but they're generally quite capable of understanding and providing input to such documents.

I mean, the chart is still useful to have, and it'd be a couple of methods probably had I written it. But it's not a huge state space, and most of the transitions are fairly reasonable.

I can imagine it was quite a lot of work to come to such a clean and relatively simple chart.

Coming up with this chart from a generic ticket like "impl notifications" is one of the hardest parts of being a developer.

Code is generally the easy part once you know exactly what you're doing.

> one of the hardest parts of being a developer.

Not least because it's really the product designer and product owner's job to make this kind of chart.

Which they never do to a satisfactory level (in my experience). So it still falls on the developer to do it properly, then PO just copies it for their presentations.

The "User in DnD?" box made me chuckle.

For other readers (like me) who were confused for a few seconds (maybe because I don't use slack?): Do not Disturb.

Because they're playing Dungeons and Dragons.

Butterfield hasn't graduated to Advanced Dungeons & Dragons yet? About time.

Do not disturb.

Yeah, I got burned by Slack recently.

I expected mobile notifications to fire no matter what... but they will only fire if you are not on any other client (desktop) and if the app is not running on the foreground.

According to that chart you have to change your Mark as Read setting... who knows where it might be though

There's a top-level tab called "Mark as Read" in the preference pane.

The equivalent of this for sending a text message through the telco I dribbled with is the 4500 line nested if-clause in the 65k COBOL source file.

Then for each check its a tour into another 60k beast with the main flow in a much handier 2k loc if-clause. And actions to be done are sent relatively straight forward from there, where needed.

But its OK, avoiding objects isn't too bad, its but after 30 years a lot of things in flows get added multiple times out of fear of breaking stuff, and it adds visual bloat.

Recently we tried to start using Slack for our local sporting club. We added our club google account to access files but this account also had all members in mailing group or something like that. Little bit after we added that account all 60+ members started receiving slack notifications and tens of them. Probably we hit some edge case that is not covered in the fow chart.

Nice! My PM and I put together a few flowcharts for a feature last week which made it much easier to implement (otherwise it was just a jumble of words on paper).

Not mentioned in this flowchart is that sometimes one element of the flowchart breaks previous assumptions and required refactoring a bunch of code. Oh well!

It's pretty good that they even have this flowchart...

It looks like maybe a page of code / if statements.

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.

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.

I think it might be cause no one really knows what you're building until it's been built. Only until then (or even a little later) does the structure of the thing become apparent. Until you've got something most people agree is what everyone wanted, requirements are basically mush and so the code is too.

That's a really good point.

The cleanest code I've ever written (and got complimented on by others) was when I was the main dev on a rewrite of a legacy system. It's easy to focus on clean/well-tested code when you don't have to worry about business decisions and customers' main concern is that nothing changes, even existing bugs!

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

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.

> really did not like someone demonstrating a working prototype

In my long and painful experience in software development, almost no stakeholders like being shown they've wasted time and effort on something even if they were told from the start it was a waste.

(Although I suspect the kind of people who would be pleased to see a working prototype are also the kind of people who would listen to reason in the first place...)

> I got a thorough chewing out for disrupting their processes

Had that a few times. Been eased out of contracts for it too.

It's not clear from your comment which context you presented it in. It's definitely embarrassing for people to have this sprung on them unaware, especially presentation-style in a big room. You gotta show people stuff like this in private, 1-on-1, in a very casual "hey, what do you think of this little hack?" kind of way. People are a lot more receptive in that context, and if they have time to go away and mull over just how much time you could save them, and help them get done, they might actually like it.

In short, don't embarrass your coworkers.

Fair point. I don't think I did it the crass way, but it's been quite a while and I'd tried to forget about the whole thing. I do remember showing it to a small group at first and getting the overall reaction of "but that's not the way we'd planned to do it!"

> In short, don't embarrass your coworkers.

This can't be overemphasized. And if you're in a situation where you have to decide between embarrassing your coworkers and going along with terrible ideas that waste time and money, then you may wish to decide to change part of the equation (e.g. removing yourself - or your coworkers - from the situation).

I don't think there is much you can do in these sort of situations. There is usually a layer of politics complicating things as well. Unless you are in a position to fire the team responsible then moving on is probably the best response.

To achieve a successful career, being good at navigating the complexities of people is often, if not more important than being good at navigating the complexities of code —- even in an engineering role.

Yes, but where does that leave you. In an organisation that punishes productivity and initiative.

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

They aren’t there to solve problems. They’re there to receive their paycheck :/

This. At my previous company, the primary product was painfully simple in concept -- just a standard two-sided marketplace.

The day I joined, one of the engineers told me to brace myself for the codebase. I figured it couldn't be too bad, after all, it was just a Rails app. Whew boy, was I ever wrong...

The code was needlessly complex in the worst ways. I'm talking constructors to create constructors, ill-named models that belied their true purpose. The entire thing was a self-referential mess of spaghetti. No one really knew how the whole system actually worked. The app probably had over 400 models, and half of which were probably obsolete.

It was obvious that over the years, no one ever took the time to clean up the code, and people just kept pouring more mess on top of it to meet deadlines. With such a messy codebase, even the smallest change that should have taken hours would take days or weeks.

I came to a new company and built a working prototype of something in a few weeks that apparently, a whole team had failed to do in more than six months of struggling. I didn't know that the project had already been attempted. Some people really didn't like me after that.

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.

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

That's an interesting perspective when you consider that:

1. Bing has at least 5x the market share of DuckDuckGo in the US (and even higher worldwide)

2. DuckDuckGo uses Bing as its main source of search results.

Anecdotally I just see a lot more people using DuckDuckGo as an alternative to Google. I will be the first to admit that I was clearly wrong in my assessment.

> 2. DuckDuckGo uses Bing as its main source of search results.

Is this still the case? I thought they now produce their own results.

DDG is a little bit vague about it on their website, but their staff regularly mentions that the results are primarily from Bing on /r/duckduckgo, for example:

https://www.reddit.com/r/duckduckgo/comments/g8wukz/duckduck...

Bing was my secret weapon when doing data science contracts that were MVPs or side features.

Take a couple million preselected strings they needed to match to and then run them through Bing, page through the results, and build up the corpus I needed out of something like mechanize / nokogiri / headless browser.[0] Then clean up the data the normal data science way then do whatever mathy stuff I needed to layer on for whatever app they needed. There you go mister client something that has billions of dollars of R&D behind it and cleaned up for your specific use-case. You want something better? Go off and hire a team of Phds and spend a couple years and 50x the money I charged you to get your RoC curves (or whatever) looking 10% or 15% better.

Haven't done this in a couple years due to a startup and then after that randomly finding a client I liked working with so much I haven't needed to take on random jobs again, but I'm sure it would still work.

[0] I had also written custom tools to make this easier / saner. Also inspector gadget + CSS selectors goes a long way too.

I'm curious what about Bing made it specially suited for this?

Absolutely fantastic rate limits (essentially a non-issue) and no captchas or other other annoyances. Reasonable enough data quality. It's no Google, but it's not bad if the search terms are for scientific concepts or similar.

That is not a scalable practice. You may have been able to do it, but if it became a too common a practice among developers making similar things then I'm sure Bing would have taken steps to limit such activity.

That's why it was a secret weapon and not a "I told everyone how to do it" weapon.

Also, lol, I spelled it "RoC curves" I clearly didn't proofread this.

I'm pretty sure that's how you spell it: https://en.wikipedia.org/wiki/Receiver_operating_characteris...

I mean, on a good day I capitalize the "O" in ROC.

Oh right! Yeah, and now there are "roc" acronyms everywhere, like AMDs rocm or whatever, and I'm pretty sure I've seen a few other. Pretty easy to get confused.

Edit: I knew I wouldn't get the capitalizaton right, AMD's is ROCm for "Radeon Open Compute" and who knows what the "m" stands for.

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

DDG is not in the index-all-the-web business. For the most part they are just serving Bing's results, that's the only reason why they operate with so little funding - it doesn't take much to operate a glorified proxy. Microsoft's footing the bills for the actual web search operation and I'm sure it's way above 13M.

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

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

Google+ isn't a fair counter-example. From a technical perspective, it very well could've been. The failings of Google+ was social.

> > Scale and Money

> This is too simple of an answer

Writer implied necessity, not sufficiency.

I didn't see it, but if others did, then I stand corrected.

I've been playing armchair QB for 20 years, my QBR is 91. Nobody is seriously saying index all of the world's information in a weekend. They're saying that the tech to index the web and otherwise has increased in the last 20 years, which enables you to do more. Google isn't even a great example, considering how intensive it is at scale. There are a lot of apps, especially with user created content, that don't have that issue at all. Your argument is the other end of I can build Google in a day, it dismisses criticism by making it absurd.

The "I could build it in a weekend" is certainly one extreme, but I think even people who say "I could build Google in 3 months" (or even 6 months, or a year), just don't get it.

And yes, there are actually a decent amount of people who say, literally, "I could build that in a weekend". Not sure how many people say that about Google, specifically, but it comes up often enough. This post was also from 2016, and I do feel like it used to come up more often in years past than it does now.

Most of the people I know, who say “I could build that in a weekend” mean that they could build a product that solves 90% of the problems in that problem space in a weekend.

And that’s true. The other 10% is what gives you competitive advantage as a product.

The truth is that _if_ the market was empty at the time; then those 90% would give you enough runway to finish the rest of the 10% with a certain high enoufh probability.

I can't speak for anyone else, but as someone who has literally said that on several occasions, you've perfectly summarized ( 90% of :) ) what I generally mean.

In addition to all the above, there is money in the “long tails” of search. At scale, even the 0.01% use case will have thousands of hits per day. This is already true at DuckDuckGo’s current scale of ~50M daily traffic [1] and even more so for giants like Google or Baidu.

[1]: https://duckduckgo.com/traffic

I've always thought there is little point trying to attack a company like Google directly. Rather you would be better trying to carve out a niche. For instance why isn't there a search engine dedicated to what programmers need.

I've seen people saying Google have effectively given up indexing the entire web. Pages older than 10 years don't tend to get indexed anymore, for example. Similar for search in gmail.

...and time. DuckDuckGo is 11 years old and just getting started.

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

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

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.

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

Their 2010 revenue was $29.3 billion, and in the last four quarters (including the recent Q1 announcement) they raked in $166.71 billion. If your headcount numbers are correct, and they've gone from 25k to 100k employees, they've actually managed to increase their revenue faster than their headcount.

Their constant failure to make a dent in the chat app space is surely embarrassing, but having a few parallel efforts is a drop in the bucket in terms of efficiency.

Facebook have 2 successful chat apps (Whatsapp, Messenger) and 2 successful social networks (Facebook.com, Instagram)

One of those chat apps was already enormously successful and then Facebook just bought it. The other was a natural outgrowth of Facebook.com being a successful social network, you may as well claim that Instagram is also a successful chat app.

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

Given that I agree with this premise, it's interesting that I come the exact opposite conclusion. If 99.9% of the work is in the iteration after the MVP, then when someone says "I could build that in a weekend" it's totally fair to say "'That' is only 0.01% of the work". Hard work that it may be to put out an application, none of that matters when no one uses it. Conversely, easy work that it may be to come up with an idea that has already been done before, if it's successfully marketed and developed into a product with traction and then ends up being the first of its ilk to be the runaway success, then you end up with Google instead of Lycos or Yahoo.

I think his point is that reducing successful companies and products to implementation is to miss the forest for the trees. Traction is hard. Execution is everything. If it was easy, everyone would be able to do it successfully.

Small businesses innovate. Big businesses consolidate.

Figuring out how to maintain a small business pace of innovation while achieving the consistency and economies of scale of a big business is basically the tech industry's quest for the holy grail.

Isn't that exactly what Amazon is doing?

Sorry, I don't really see why.

Amazon's big success stories recently have been about providing the infrastructure for other businesses, both in its retail storefront and with AWS. This is one of the tried and tested strategies for big businesses to exploit their greater resources while not actually having to do the grunt work to create new products or services that end customers are willing to pay for.

Amazon is not a moonshot factory inside trying hundreds of ideas small & scale the successful big?

You think AWS was planned ahead for years and everything that runs on top of it?

If AWS was such a logical consolidation why has Amazon such a big market share of the cloud and can even Google & Microsoft barely catchup with the innovation?

Did you ever speak to an engineer working at Amazon or is this some feeling you have??

I talked to Werner a couple of times and everything he told me disputes your personal assumptions.

The commoditization of logistic and compute infrastructure is real innovation although it looks like consolidation from the outside.

Amazon as a whole has nearly a million employees and generates 12-figure revenues. It would be remarkable if it had no R&D at all happening outside its main activities.

But imagine if you could take the more capable people who work on Amazon's high-tech systems like AWS or logistics automation, bundle them into well-composed teams of a few people each, and give each team say $10M in funding. You've potentially just created more highly capable startups with enough runway to do something worthwhile than YC has funded in its entire history. Tell me with a straight face that Amazon as a whole is innovating as much as the combined portfolio of YC from day one.

How much of YC innovation is possible because it runs on AWS commoditization of server hardware ?

Is the annual revenue of all YC companies combined larger than Amazon? (I really have no idea but the it would be the only objective measure of your comparison, brownie points if you reply the answer)

How much of YC innovation is possible because it runs on AWS commoditization of server hardware ?

Innovation? Probably not much. Running on cloud infrastructure is hardly innovative in 2020, there are several other viable choices apart from AWS, and of course before cloud people were running systems in data centres for a long time.

In short, infrastructure like AWS might make some things easier, but it doesn't create much potential to do anything radically different. Big businesses consolidate.

Is the annual revenue of all YC companies combined larger than Amazon?

I don't think we can tell, because a lot of YC companies are private and don't necessarily publish their figures. Amazon's reported revenue rate is in the region of $300B. YC has a portfolio that includes unicorns like Stripe and DropBox, but also a long tail with many less successful or now-failed businesses.

It seems unlikely that the YC portfolio out-earns Amazon, but this isn't really a useful comparison. For one thing, my figures before were only looking at the tech side of Amazon, and completely ignored major factors like Amazon's huge retail operation and most of its acquisitions over the years. For another, it would be no surprise for the big business with huge volumes to bring in more revenue. Small businesses innovate, and innovation is often more about potential revenues in the future than actual revenues right now. Big businesses consolidate, and consolidation is all about scaling up once they've found something that works.

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!

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.

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.

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/

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

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

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.

I recommend the Just Read add-on. It does readable formatting for you and sometimes even removes paywalls popups.

I quite like http://bettermotherfuckingwebsite.com and all the variants you get if you google "motherfucking website"

The author seems to have given this topic some thought [0].

Personally, I did not experience any problems reading it on my ~50cm wide monitor.

[0] https://twitter.com/danluu/status/1228041917272715264

Resize your browser window. It's a flexibility most "modern" websites deny us.

Just resize the window?

browser > reader mode FTW! Really, it's that simple!

I also couldn't read it on a 27" 4k monitor, just closed the site. I tried with zooming in, but it was still too much of a hastle.

What are you saying, that the font was rendered too small? This is a configuration problem.

You might consider setting your browser's default font size to something appropriate for your DPI.

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

Rotate your monitor by 90 degrees for a better reading experience. If this is not possible, buy one that can.

Until it arrives, use the Reading View of your preferred browser.

Do you actually do that?

I've tried it. In portrait mode, my old 24" 16:10 monitor is already tall enough to wreck my neck and be really uncomfortable to read. I wouldn't even want to try that with my current 27" 16:9 monitor..

Just how close to your monitor do you sit? I have no problems with my 24" 16:10.

The nuisance for me is actually rotating the monitor, particularly if OS support for detecting such and automatically rotating the view is missing. So while I like portrait mode, I tend to just keep it one way or the other, based on my overall monitor configuration.

> Do you actually do that?

Yes, of course.

My monitor can roate 90 degrees, but I prefer it landscape, it's more ergonomic not to have to tilt your head vertically, your eyes are horizontal.

> My monitor can roate 90 degrees, but I prefer it landscape, it's more ergonomic not to have to tilt your head vertically, your eyes are horizontal.

It's more like looking at an ordinary A4 page.

to be fair, I was relearning to just resize my window.

Sounds like a client issue. What CSS are you viewing the page with?

Better than hardcoding some fixed or percentage width, leaving 5 inches of wasted blank space on the left and right side of the page, like many web sites do.

There's not even a <body> tag. It just has some header information and jumps right in to the text, but he took the time to add Google Analytics. It's so bizarre.

You do know that the <body> tag is optional in HTML5? From MDN: The <body> tag “may be omitted if the first thing inside it is not a space character, comment, <script> element or <style> element. The end tag may be omitted if the <body> element has contents or has a start tag, and is not immediately followed by a comment.”

However, in this particular case the body starts with a space character, so it should have a body tag.

A minimal valid HTML5 document looks like:

    <!doctype html>
    <meta charset=utf-8>
    <title>blah</title>
    <p>I'm the content

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.

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.

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

Firefox reading mode. It saves me 2-3 times per day. Don't know how I ever lived without it!

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

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

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.

It should have a sane default. The current default presentation is not sane.

Your user agent should have a sane default. The idea that every text document on the web should ship their own default is insane.

I used the Stylus browser extension (https://addons.mozilla.org/en-US/firefox/addon/styl-us/, https://chrome.google.com/webstore/detail/stylus/clngdbkpkpe...) to add this style to the page:

danluu.com – more-readable text

  body {
      max-width: 65ch;
      line-height: 1.3;
      
      /* center the body in the viewport, and then add padding to make up for the default margin we overwrote */
      margin-left: auto;
      margin-right: auto;
      padding-left: 0.5em;
      padding-right: 0.5em;
  }

I’ve had that style on for so long I forgot about this site’s terrible defaults.

I did this :

    body {
        max-width: 600px;
        margin: auto;
        line-height: 1.7em;
    }

Much better :)

No... Premature presentation is the root of all evil! :) This is content, not art.

Yeah, plus, I should be able to view this page with JavaScript and my entire browser disabled/uninstalled.

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

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

> It’s not that these other things don’t matter but all the “other stuff” shouldn’t take priority...

Totally agree with you; I think the sentiment behind "I could do that in a weekend" is that shipping the core functionality can be done quickly, and iterating on the "other things" can be done after launch in many cases. Not everything has to be as robust as possible on day one. Google didn't have BigTable, MapReduce, and Borg the day the search bar went live. Shipping features is my favorite part of the job, it'd be great to have those wins as often as possible and cross other bridges when we come to them.

A lot of it depends on scale. At facebook's scale (user base and revenue), it's worth paying 10 engineers to make little tweaks in a narrow area of the product because that little polish, while not worth doing for a smaller company, may bring in an additional 10s or 100s of millions in revenue. Similarly for tooling. Most shops can and should use stuff off the shelf. But when you have thousands or 10s of thousands of engineers, making all of their lives even a little bit easier is worth putting together a team.

Simply because there is demand for that "other stuff" that you are writing off. Every user and organization has their own workflows and are looking for different things when they spend money on a piece of software. What you consider a core feature others may not use at all.

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

I think the HN comments about "what do they all do" are more often than not inquisitive ... or not entirely off the ball as far as "This product could be great if the company running it wasn't trying to be a unicorn and thus spending all that money with little more to show for it."

I don't think those are unfair questions / concepts.

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

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

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.

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.

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

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.

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

Should be marked "(2016)"

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.

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.

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.

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

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

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

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

When a taxi company here contracted to build their own hailing app, it was done to the tune of €500-600K. Every bit as good as the big rideshare apps.

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.

https://en.wikipedia.org/wiki/Coastline_paradox

The devil is always in the details.

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.

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

Discussed at the time: https://news.ycombinator.com/item?id=12626314

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

They lose customer data and then end up in newspapers.

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

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.

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.

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.

I could have written this blog post in a weekend.

(I know, downvotes incoming. Worth it)

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

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

There is a simple recipe:

1 part arrogance.

1 part optimism.

1 part naïveté.

Do not over mix. Bake half way.

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.

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.

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

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.

> every developer who could possibly build your app

well haven't they? a competitor doesn't need to be a copycat. like how, e.g. google bought deepmind

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

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.

Reply on news.ycombinator.com