One other thing he touched on in passing: people are assuming they'd know what to build from the start. Even in relatively trivial applications a lot of work goes into finding the right way to express what you're trying to build. I recently worked on a small app and spent 40 hours trying out different approaches to the user interface. The solution I went with could be coded up in about 2 hours, but I had to do 38 hours of work that eventually got thrown away before I arrived at it.<p>This sort of thing happens all the time in professional software development. Sometimes it <i>is</i> a waste of time, e.g. people rewriting things in a new language/framework for negligible benefits, but a lot of it is a necessary part of developing a polished app.
I think this article raises a lot of good points about the weekend prototype, but I also think there is some merit in the question of “what do all those people do?”.<p>I’ve worked in digitalisation in the public sector of Denmark for quite some time. A few years ago I was part of the group who redefined our national principals for architecture in municipality IT systems. The whole thing is called rammearkitekturen which translates directly into “the framework architecture” and without getting into too much details it was made because we had 98 muniplacities times 300 average IT systems ways or defining what a person was. Which made buying and integrating IT hard. Rammeaekitekturen still hasn’t fixed that, but that’s not what I want to talk about.<p>One of the things to come out of this mindset was how to design an IT system for eldercare. Where there used to be a physical folder with a printed note containing all the “Moksly may attempt to hit you during showers and this requires two caretakers” and so on as well as hand written notes for day to day things, medicine used to come in little sorted bags clearly labelled “MORNING” and so on, and every morning people would get a printed list of their route that was adjusted for coworkers who were off sick and so on, and that was pretty much it. Today we have multiple different billion dollar systems to handle those basic things, and after two years of being used they still can’t handle differences between day and night-shifts or giving call-in temps the correct sorts of data access.<p>Instead of having two planners and a subscription to a pharmacy for the sorted medicine bags, we now employ almost 50 people as full time support staff to operate this system as well as throwing endless amounts of resources after project managers, lean consultants, educators and so on to get this system to work.<p>When polled everything single citizen and caretaking employee replied that the old non-digital systems were better. At no point has anyone asked whether or not it made sense to digitalise this area or if it makes sense to continue trying to implement it.<p>So I do think that it’s sometimes reasonable to wonder just what all those people are doing in some organisation. Because sometimes systems have a way of making themselves important to the organisation without actually being important to the organisation.
This is an excellent summary of the non-obvious realities of building software at scale. Engineers often become so good at building quick, weekend prototypes that they don’t understand the realities of shipping software at scale. Practically speaking, the initial greenfield software development is almost always a tiny fraction of the effort that goes into building a business.<p>This is a common downfall of engineers who try entrepreneurship before they’ve gained managerial or operational experience. I’ve lost count of how many entrepreneurs I’ve talked to who got something running on an Arduino or Raspberry Pi and think that they’re one step away from a successful business. Really, the hard work is only beginning.
Similar thing with comments whenever a Slack related article ends up on HN. "I don't understand how a shitty IRC clone is worth billions of dollars!" or "Why would anyone use Slack when Matrix is free!" I often wonder if these folks haven't even bothered to actually use the software and realize how much more it does beyond sending messages back and forth and/or how much detail and thought goes into making it usable for the masses, not just software engineers.
I don't see nearly as many people claiming Google could be built in a weekend, but I do see that sentiment a lot in threads about Uber. It's easy to think it's a simple app, but there was a great response from a former EM highlighting just why that isn't so[0].<p>> This reminds me of a common fallacy we see in unreliable systems, where people build the happy path with the idea that the happy path is the “real” work, and that error handling can be tacked on later. For reliable systems, error handling is more work than the happy path.<p>Is there a name for this fallacy? I think this isn't merely a familiar anecdote, but something that points to the root of why armchair architects think things are easier than they actually are.<p>[0] <a href="https://news.ycombinator.com/item?id=25376346" rel="nofollow">https://news.ycombinator.com/item?id=25376346</a>
I've seen this so often. Almost every time something about Khan Academy's technology makes it to the front page here, someone brings up some form of this complaint. It got to the point at which I wrote a post [specifically to address why Khan Academy has so much code](<a href="https://www.kevindangoor.com/posts/why-khan-academy-has-so-much-code/" rel="nofollow">https://www.kevindangoor.com/posts/why-khan-academy-has-so-m...</a>). There's just so much complexity involved in making reliable services that provide features used by a variety of types of users.
> A company that could eliminate organizational inefficiency would be a larger innovation than any tech startup, ever.<p>Fully agree, and would extend to any social organization. One of the most important aspects of organizational efficiency is managing the signal/noise ratio of internal communications. We now have the ability to turn effective bureaucratic protocols into material reality with automated information systems.<p>The organizations, whether private or public, that best tackle this problem will come out on top on the 21st century, regardless of ideology and historical advantage.
Sounds like the Pareto Principle at play: 80% of the product is created with 20% of the effort. It is getting the next 19%, then 0.9%, then 0.09%, and so on, that is the challenge.
Sometimes, though, you <i>do</i> need to scale back to a weekend prototype. Understanding what it takes to scale the system is good, but the analysis paralysis from imagining that every problem must have a Facebook-scale solution is silly too.<p>I mean, those Volvo XC90s are damn slick, but somehow my local pizza place delivers hot tasty stuff on time in an old Fiat Seicento. I think the pizza quality would suffer if the owner invested in a more reliable and better car.
Fun article, but exceptionally difficult to read. I know some people like using plain ol html, but just a few lines of CSS would vastly improve the reading experience. I know its from 2016, but still.<p>Eyes read best when content is a few hundred pixels long. Content should be centered etc.<p>It's pretty terrible as it is
If you're going to make this criticism, I feel you also need to be capable of recognizing when such criticism actually is valid [1]. That is, under which circumstances would someone be justified in saying "okay this is not an optimal problem"<p>(A famous example from the other direction was when Uber re-engineered a querying service to better fit the use case, where several HNers and a Medium article showed why their re-invented wheel was worse than an off-the-shelf solution that they just weren't using correctly [2].)<p>If you can't satisfy that, then this feels like a fully-general rejection of <i>any</i> claim that an org has over-complicated a problem or has unnecessary bloat, and/or that no one can criticize until they've personally worked (for n months) at the org. Which itself would be hard to defend.<p>[1] Based on my "Scylla-Charybdis"/Goldilocks Heuristic: <a href="http://blog.tyrannyofthemouse.com/2015/12/the-scylla-charybdis-heuristic-if-more.html" rel="nofollow">http://blog.tyrannyofthemouse.com/2015/12/the-scylla-charybd...</a><p>[2] <a href="https://news.ycombinator.com/item?id=21537008" rel="nofollow">https://news.ycombinator.com/item?id=21537008</a>
Any chance you could add, that wide text is really hard to read
body > *:not(pre) {
max-width: 600px;
margin-left: auto;
display: block;
margin-right: auto;
}
pre {
max-width: 1200px;
margin: 40px auto;
background: #f6f6f6;
padding: 16px;
}
We were just having this discussion around the Postman fundraise - various people saying "its just a GUI around Curl!!!" and being all offended at the raise's price tag. There's so much more that goes into building an actual business.
One other thing is, many of you could write something like a mouse driver in a weekend. That is not enough for the business however. The UI needs to be Electron based for easy maintenance, and you need to add telemetry, because how else will you know if people actually use your product? So you need backend and API teams too for each platform.
I suspect this is connected to the happy path coding phenomenon. The core issue probably IS that easy. But you need to cover all the edge cases reasonably well too to have a business and those you can’t necessarily see until you start coding
One could build a self driving prototype in a weekend of hacking (using the libraries, tooling, etc available) and train it. I think it's a perfect example of the weekend prototype vs production reality difference.
"I could do that in a weekend" is obviously idiotic but why choose Google as the example (possibly the hardest piece of software to replicate)?
maybe part of the whole conversations is survivorship bias? id be interested to see data on the past positions and companies people on both sides of the argument have worked on. ie: if you have seen how teams of hundreds are justified, it makes sense. likewise, if you have only worked on small teams, its hard to understand what 100s of engineers would do.<p>its been a few years but i knew of multiple alexa-100 sites that were all running on just two 4 core servers(this is back when alexa was a useful measure of size, mind you). managed essentially by the hosting company. so "scale" is not always directly linked to traffic, i would think complexity dictates the need for more engineers rather then size.