Ask HN: Why are big companies so much less efficient? - <AUTHOR> I've worked on companies big and small (relativley; smallest was around 400 people, though engineering was closer to 160-200). One thing that has struck me is that, in my opinion, smaller companies seem to get much more done per engineer than bigger ones. I'm curious-- has everyone else has seen this too? In your opinion and experience, why do you think this is?
Is this the overhead of decision-making (one person or the engineer deciding vs a chain of command)? Is it that people are just more motivated when they're the underdog? Is it that the inherent size and complexity of a codebase grows exponentially as people grow linearly with time? Is it that some products seem to be "done", and changes are iterative and pedantic, not risky and exciting? All of the above? Maybe even some more?
I'd love to hear your stories and thoughts! <comment><USER2> There are a hundred valid answers to this question. Here's one that I think is a major factor: What is the degree of separation between the engineer, and the people who benefit most from the engineer's work?

If you're a startup founder, you eat what you kill. There is no degree of separation at all.

If you're working at a 10-person startup, you report directly to the founder. 1 degree of separation.

At a 50 person startup, you probably report to someone who reports to the founder. 2 degrees of separation.

At a place like Microsoft, you're probably 7-8 degrees removed from the CEO, who himself reports to the board-of-directors, who report to a decentralized mob of shareholders.

At every degree of separation, there is an amplification of:

\- distortion of incentives

\- "Not my job"

\- "that decision is above my paygrade"

\- "What's in it for me?"

I don't think individual productivity can ever be as high in mega-corps, the way they are in startups and smaller teams. Hence why mega-corps are generally best at milking existing cash-cows, whereas startups are much better at actually driving innovations.

<comment><USER3> If that were really true though, wouldn't a big company solve it by splitting itself apart into smaller parallel units all doing the same job as each other but with shorter hierarchies and not wasting time communicating with each other? I think economies of scale still overwhelms the chain-of-command losses you described and makes big companies more efficient overall.

<comment><USER4> might just be big (Big! like google) companies have only been around for so long. I don't know of any company that has tried something like that, maybe it would work great!

</comment></comment></comment><comment><USER5> Communication overhead.

You've seen those graphs about how lines of communication explode combinatorically. Once an organization hits ~20 people, if they're all communicating directly and keeping up to date with everything they need to know, everyone could be spending every minute of their day communicating and not getting any other work done.

In order to cope with the communication overhead, larger corporations add management hierarchies that maintain linear communication "vertically" and smaller group sizes for "horizontal" communication. They also add processes that decrease or streamline the amount of communication necessary. Management and process are _necessary_ to keep the company from grinding to a halt under the weight of its own communication overhead.

However, management and process even when done well will add a certain amount of overhead and slow things down. Less than they would if every engineer had to check with everyone in Sales and Marketing before deploying any change in order to make sure that a deploy wouldn't disrupt a major campaign. More than you and your two co-founders sitting next to one another and asking "hey, I'm gonna deploy the Foo feature now - is that cool?" And when done poorly, management and process slow things down even more.

<comment><USER6> Why is "communication overhead" still relevant, when today, huge open-source groups cooperate very effectively ?

<comment><USER7> [Citation needed] -- Not saying this to be glib, but I'm just wondering what is an actual "huge open-source group". From what I can tell, most open source projects are heavily maintained by a single-digit number of people at any one time.

</comment></comment></comment><comment><USER8> I wouldn't say less efficient but with larger margins. I could probably do the work of 2 my colleagues if I was really pressed and was forced to work overtime. Instead, I work something like 5-6 hours a day. This sounds like inefficiency - however, when people get sick, when they go on holidays, when new products are to be released and we need to do something extra fast - it's business as usual and no extra sweat is involved. Pure comfort for everyone, including the marketing and sales teams.

When I confront it with the times I worked for a small company... You had no choice but to work hard. If you didn't do it, it wasn't done. Deadlines were pushed forward, everybody was unhappy. There was no margin for anything, so I had to work overtime very often. These two approaches are incomparable. (Of course you can easily find opposite examples, especially in big consulting firms, so take this with a grain of salt.)

<comment><USER9> > _You had no choice but to work hard. If you didn 't do it, it wasn't done. > Deadlines were pushed forward, everybody was unhappy. There was no margin > for anything, so I had to work overtime very often._

Can echo that this was my (small, well-funded, widely-used) startup experience as well. Going into a bigger organization after this was shocking in terms of how lax people worked.

<comment><USER10> I worked at a few clients in SF, CA a couple years ago. As a consultant 40 hours was the minimum. It was also my maximum.

I'd get to the jobsite at 6-7am (avoiding traffic/crowded trains/buses). I'd go to lunch at 11am and leave around 3-4pm depending on how many hours I'd been there.

I'd see the employees rolling in at 9:30-10am. They'd eat their breakfast, so SCRUM at 10:30am. Then they'd take a 2 hour lunch and at 4 or so when I was leaving would have to go "pick up the kids" or "doctor's appointment" or any of 100 other excuses they had.

I had someone ask me once, "How many hours are you working?" (implying I was there a lot). I said "Forty, how many are you working?" (implying the 26 or so they were actually in the office).

I called it California Time. It wasn't at one company, it was at every medium to large company I went out to as a consultant or contractor.

I guess if they were achieving their goals, it wouldn't be a big deal, but when you've got $250+/hr consultants in there helping, you're not.

<comment><USER11> Wow, were you part of a consulting firm? did they find you the placements?

</comment></comment></comment></comment><comment><USER12> Big companies tend to optimize for business continuity rather than pure efficiency.

It is a systems tradeoff.

You can hire 5 10X people, but if one of them leaves (10X invariably do), you would have a harder time replacing, on-boarding, ramping up, culture-indoc, etc. another 10X person, assuming you can find one. In the mean time, this could potentially mean anything from a chaotic breakage of process or severe team reorg.

Whereas if you hire 50 1X people, if 5 leave, the system will likely still run at reduced capacity while you backfill if you have good process (not all big companies do, but those that survive in competitive industries tend to).

Good process often wins over a concentration of pure talent over the long run.

<comment><USER13> I don't know about 10x people, but I think startups attract people who like efficiency. People who hate wasting time in meetings. However for big companies meetings seems to be like a drug.

The startup I work for that went from 3-30 people over the years was bought by one of 100,000.

I keep wanting to have meetings of 2/3 people and the people I come across at the new company love having 6+ people in a meeting.

<comment><USER14> I like small companies because they let me get things done. "Solve this problem." and I'd solve it. That could mean cleaning up some workflow, or building 5 automation engines.

This gets more difficult when you have modules that have more than one person coding on it, because now you can step on each other's toes.

Big companies usually have 7-8 people working on a particular module, which requires a lot more coordination. That module is probably spec'd out by another team of a few people who talks to the business teams that will be using it, or talk to a client. These teams all have managers who need to know what's going on, so they have more meetings. When there's a question on the spec, it now involves two teams that must have a meetings to talk. Teams ask questions of other through their managers which leads to more meetings. The original, "Solve this problem," was defined by an upper level executive 5 levels up, based on some grand strategy that I don't know about and won't be explained to me.

It turns into a big mess.

</comment></comment></comment><comment><USER15> So I think another factor that hasn't been mentioned is that at a large company there is often an aversion to two things: breaking existing services and duplicating work that another team already "owns" (the second part is normally done in vain, but still wastes time, as you can see by Google's message app mess). This results in slower agility already, because if someone would like to add a new feature, there needs to be some degree of communication with owners of the needed projects and coordination across teams. All of this takes time away from producing tangible work. The reason that this continues is because at most large companies (at least tech megacorps) _this inefficiency is a rounding error_ compared to the boatloads of money that the company rakes in. The system in place keeps the ship moving and delivers innovation at a manageable pace, and as a result nothing in the organization structure really changes because the company continues to profit, and everyone internally reaches their objectives:

\- Upper management: company is making money

\- Middle management: engineers are doing work, projects are coordinated

\- Engineers: projects move slowly, but getting paid and promoted and gaining experience

None of these objectives are "streamlining organizational structure"

<comment><USER16> Surprised this is the only comment mentioning the duplication of work problem.

</comment></comment><comment><USER17> It's like going to lunch with a group of people. If it's just you, you can go wherever you like. Once it's with your partner, you have to take their interested into account. Have you tried planning a lunch for 5 or more people, taking into account dietary restrictions, location, time, etc.. ? And imagine when it's 400 people - now you need to make sure the restaurant can hold that amount of people, and if it's available during times that you like. The more people that are involved, the more variables are introduced that influence decision making.

<comment><USER18> Or a music festival where multiple conflicting acts are playing. Getting more than 2-3 to agree on a thing to attend is a nightmare and it just descends into sitting in the beer garden listening to whatever.

<comment><USER19> Or, you know, all going to see whatever you want and meeting up when you can. Festival protip: there's no law saying a group must stick together the entire time

<comment><USER18> That is what I am saying. Trying to coordinate a group is a losing proposition where it descends to LCD. Flocking vs herding, flock for discovery, herd for safety.

</comment></comment></comment></comment><comment><USER20> Depends I think - big companies are vastly more efficient than small companies at certain things.

To give a personal example from a FAANG, where I work at, web developers don't have to worry much about a lot of the ops infrastructure - a lot of that work is offloaded to another org whose sole responsibility is to have a robust setup for the whole company. We don't have to reinvent the wheel for things like CI/CD, and such nice features like deploy on a pull request basis. The main inefficiency I see is that large organizations take time to make the decision of whether something is the right thing to build. Once the decision has been made, the implementation happens much faster than what small companies can match that I've seen - my own employer moves frightfully fast compared to any startup I've worked for.

From personal experience, I see small companies constantly struggle with trying to standardize these things, and often solve these problems in a way that causes long term iteration pain. Oftentimes the engineers aren't good enough to solve many of these problems, and the short-termism of feature development strangles a lot of proper solution building, which actually leads to a lot of inefficiency.

A lot of times, small companies also often take shortcuts that bigger companies cannot take. For example, internationalization and accessibility may be minimum requirements at some bigger companies, whereas small companies may not be hamstrung with supporting those fully for their customers, if at all.

<comment><USER21> I'm d'accord with that. I think many comments here have a misconception of efficiency versus flexibility. For me it breaks down to:

\- Big companies are: More efficient but less flexible

\- Small startups are: Less efficient but more flexible

Big companies are more efficient because every employee has a narrow field of responsibilities. They are dedicated to just a few tasks and can leveradge from focusing their minds on just one thing (e.g. a web developer who is just responsible for programming his mobule). Compared to a small inefficient startup, were every employee has a broad spectrum of responsibilities and needs to refocus his mind often (e.g. a web developer who has not only programming tasks, but also system administration, setup/deployement, UI design, customer support and cleaning the coffee machine and fixing the printer).

Small startups are more flexible because everybody can directly give new ideas to the boss, everybody has knowledge about the whole company and how everything is tied together and changes to processes or infrastructure can easily be adopted.

I think this situation is not a bad thing. Big companies and small startups live in symbiosis. Startups are flexible enough to produce new innovations. Then they either grow big (implement processes, standards, hierarchies, etc.) or get acquired by a big company. However, big companies are not flexible enough to produce new innovations but they have the resources to found spin- offs / create new startups.

</comment></comment><comment><USER22> The Pareto Effect.

The Pareto Effect, applied to companies' productivity, states that 50% of the output is generated by the square root of the number of employees.

So, if you have a company with ~10 employees it's not a big deal, 50% of the output is generated by ~3 employees. However if you have a company with 10,000 employees, only 100 of them are generating 50% of the output; and that becomes pretty visible since each of these 100 employees knows most of the remainder 99, and most of the people they come across are "dead weight" to the company.

Give the company enough time, and the productive employees will leave to seek greener pastures, so - little by little - the company collapses.

<comment><USER23> I'm surprised this comment is buried. Your answer is correct, and it's a fundamental economic principle.

</comment></comment><comment><USER24> This going to be more obtuse from what you would expect but i can give it a go

this is because efficiency isnt a goal , impact is. you might be efficient enough to iterate 10 times a month. but that is not what a customer wants. planning goes a long way compared to just doing something. as software Engineers we often mistaken efficiency as "getting shit done". which is great but there are too many instances when it is shit. the bigger the org and the user base / affected population, the things you do has an impact . i've known users to shift loyalty due to small mistakes that companies do. as a dev deeply connected to the impact of your product, you realize that decisions make a big difference. you plan ahead and mitigate probable failures. these require time.A good product can go a longer way than an efficient team with no direction. this does not imply that everything takes time. but repercussions of a bad decision can be lasting in a big organisation. you have a large number of stakeholders involved who would want to and can help you achieve your goal. this is however not always good. the greater amount of red tape involved can lead to competitors gaining an edge and also several cases of "i fucked up". the bottom line being. efficiency isnt merely moving fast. its about building things which matter and having an impact. if you look at efficiency in that manner, then big orgs aren't any less efficient than the smaller ones since their reach is much greater. perspective matters

</comment><comment><USER25> In my personal experience, complexity of the product.

Anyone can start a new product with 1/10th of the features of a competitor and feel that large corporations are slow and inefficient.

Hammering out all of the edge cases and flushing out a product is often what takes a lot of time and manpower. Not to mention dealing with a larger number of customers who probably use said product.

There are success stories of small shops who automate everything, or who offer a product that is so simple (not a knock, actually a complement) that it can be run by a small team. Complexity is the enemy to shops like this, and I think few know how to avoid it in the long run.

</comment><comment><USER26> I've worked for big companies early in my career (good place for a junior engineer to get some experience), then mostly smaller companies (where I could just walk into the CEO's office and strike up a conversation if I felt so inclined), where I got used to being multi-hatted and pitching in wherever.

Right now, I'm sitting in a cube at a huge corporation. This job was a step up in pay, but in every other way feels like a big step down. I'm pigeon-holed as a senior engineer on one very specific part of an unnecessarily complex software system (Java, of course).

I'm bored out of my mind and literally going stir-crazy - I get up and pace around the cube farm often. I leave the building and go for walks during the day as well. I also spend more time on HN than I should :)

I will never take a job with a megacorp again, ever. I want to work for a small company where I have some autonomy and the ability to have an impact on the business.

<comment><USER27> yes. you're bored. yes. it sucks. But why is this megacorp less efficient than a small company?

<comment><USER26> The boredom is a symptom of the inefficiency of the large corporation.

Actually, I'm not sure I could say it's _less_ efficient. It's just optimized differently. The company is deliberately set up to treat engineers as interchangeable cogs to minimize risk. Following the _process_ is more important than getting stuff done (and boy, do big companies love process). Also, you are "protected" in a sense from gaining too much domain knowledge or having direct communication with users/customers, and you are shuffled around every so often (Matrix management, yay).

Small companies can't afford to do that. They can't hire a legion of average performers and hope to make up for it with byzantine processes and tightly defined roles and responsibilities.

</comment></comment></comment><comment><USER28> As companies grow, it becomes harder to manage people and things, and therefore processes get created. To bring chaos to order.

Each process brings an overhead - someone needs to create the process, then some number of people need to manage the process, another number of people to document and explain the process to others and finally a group of really unfortunate people who will be forced to live with it.

All that happens is that the more people there are that need to use a process, the more people are needed to manage it. If the use-cases outgrow the process then someone else needs to come along and make a new process, and then even more people will need to come along and advertise the merits of this wonderful new process and to explain to everyone else how it works and why they should be using it. Suddenly you have more processes and more people to drive them.

You hire some more people because you realise that all these processes are all well and good but actually they aren't making you any money. All that happens is that these people are also inundated with processes and therefore are less efficient, because suddenly you're having to actually justify your work internally or to go through some kind of process and time wasted doing that is not making the company any money.

What happens eventually is that most of the people working at a big company aren't actually working towards the goal of the company whatsoever. They're just there to hand-crank a process. None of these people are actually revenue- generating, and the people who are actually there to be revenue-generating are slowed down or otherwise hindered by process.

The problem is self-perpetuating. Oh, no, we aren't making any money. How can we improve our processes to make more money? The cycle continues.

</comment><comment><USER29> You're considering the wrong part of the company (R&D) when evaluating efficiency. Big companies are efficient in terms of serving their customers and extracting money from them.

Big companies often end up buying small ones precisely to extract the efficiency benefits you cite.

Perhaps a good question is : could big companies' R&D be made more efficient?

In answering this you'll probably run into the question "who gives a crap about the things you want to be more efficient?" Most people working in big companies are focused on other stuff such as how to avoid being fired by their psychotic boss, how to get a promotion, how to get a good performance rating, how to get a better job elsewhere, and so on. Only sometimes are their motives aligned with efficiency and things like delivering good products.

<comment><USER30> > _Big companies are efficient in terms of serving their customers and > extracting money from them._

Efficient in what parameter(s), compared to the service and money extraction performance of small companies?

Big companies extract an _absolute_ bigger volume of money and provide a bigger volume of service; that is undeniable.

But a measure of some sort efficiency need some sort of denominator under that.

E.g. from the point of view of a top brass executive getting rich, a bigger company is certainly much more efficient than a small one.

<comment><USER31> Economies of scale basically. If company A serves 100 000 customers and needs $1m to do R&D of a particular feature, and company B is much larger, serves 1 000 000 customers and due to organizational inefficiencies needs to spend $2m of R&D man-months to do the same feature, from the customer's viewpoint they're still much more efficient than company A, since they have less expenses per customer, so they can either charge lower prices or afford to add more features to their product.

It's like the efficiency of Amazon and Walmart - a small store can outcompete them on some aspects like, say, customer service, but not on efficiency as measured as cost of overhead per item or sales dollar. Lots and lots of good things are prohibitively expensive unless you can spread that fixed cost among many customers.

<comment><USER30> But economies of scale are not efficient _for making money_. It's about moving more units at thinner margins. More volume has to be moved to make a buck.

Economies of scale are efficient for unit cost, for sure; the production of stuff is efficient.

Two guys laying residential bathroom tiles are more efficient at making money than Amazon, in some sense, though.

</comment></comment></comment></comment><comment><USER32> Ran across this Charlie Munger quote a few months ago that stuck with me about the problem with larger companies and bureaucracy:

"...if you worked for AT&T in my day, it was a great bureaucracy. And in a bureaucracy, you think the work is done when it goes out of your in-basket into somebody else's in-basket. But, of course, it isn't. It's not done until AT&T delivers what it's supposed to deliver. So you get big, fat, dumb, unmotivated bureaucracies.

I think that's part of it. There's a natural human tendency to want to feel like you're accomplishing things, and in large bureaucracies it's easier to feel accomplished without actually getting the things done that need to get done.

Also from Munger:

"They also tend to become somewhat corrupt. In other words, if I've got a department and you've got a department and we kind of share power running this thing, there's sort of an unwritten rule: "If you won't bother me, I won't bother you and we're both happy." So you get layers of management and associated costs that nobody needs. Then, while people are justifying all these layers, it takes forever to get anything done. They're too slow to make decisions and nimbler people run circles around them."

</comment><comment><USER33> > One thing that has struck me is that, in my opinion, smaller companies seem > to get much more done per engineer than bigger ones. I'm curious-- has > everyone else has seen this too? In your opinion and experience, why do you > think this is?

There's a couple reasons, but the biggest is that less established companies and their investors tend to have a higher risk tolerance, while well established companies tend to be more risk averse; consequently, the small companies _that survive_ get more done per engineer, on average, because they've taken a higher risk / higher reward approach. (Google often gets mocked as inefficient for taking multiple parallel stabs at the same problem, and, sure, a company which just did whichever one turns out to get validated by the market would be more efficient—but one which did only one of the losing ones would fail and be forgotten.)

Another issue that is that bigger firms are often devoting considerable resources to solving non-technical problems (like "securing enterprise and government contracts"), which often are very rewarding in terms of profit, can often be rewarding in terms of impact, but often compromise efficiency in a narrow technical development sense.

</comment><comment><USER34> Speaking more pragmatically, larger companies are much more family friendly - people guard their personal lives fiercely at large companies. At least, this is my experience at an 80,000+ employee company.

You're basically a huge asshole if you book a meeting at 3pm because you'll make all the moms and dads late for picking up their kids. And you can't book any meetings before 10am because more often than not, it's tough to get everyone in earlier because they have to drop their kids off.

Aside from that, new parents are often glued to their phones waiting for updates from whoever is taking care of their children. They are not fully engaged in meetings and I often watch their attention drift to the daycare nanny cam. I have a coworker who receives hourly updates from her mother who is taking care of her young child. Sure enough, every hour there is something that needs to be corrected and thus, a 15 min phone call ensues.

So here I am, a single software developer, who has to wait a week for our sprint planning meeting because everyone else on the team has put up roadblocks that prevent it from happening. I literally will sit here this week doing nothing because of this. This is a regular occurrence.

This isn't a complaint really, I will want these same luxuries when I am a parent, but I can't help but notice that 90% of my team would really rather be elsewhere.

<comment><USER35> I definitely sympathize with this. I mean this in the best way: many large companies are little more than adult daycares. And in many cases, it's a feature, not a bug; it's probably about as close as we can get to some sort of UBI. As long as the company is in the black and nothing too nefarious is going on, it's 100% acceptable for people to come in, put in a Michael-from-Office- Space level of work, and go home. Earlier in my career I found myself in the position where I could hide away for multiple weeks and nobody would notice, for this exact reason. I moved on to a smaller company so I could actually do things, but if I were a parent, I'd make some calls and go right back to that gig.

</comment></comment><comment><USER36> One thing that I've found is that the more people there are at a company the more people there are that feel a need to justify their job or themselves (never underestimate ego), so they feel the need to put their finger in every pie, even when they're not needed.

What I've seen happen is that a small group will try to get something done quickly (with the CEO or COO's or whomevers blessing) but then other people will get wind of it and say hey, I'm the XXX of Marketing, you can't do that without me, or I'm the XXX of Project Management, you have to follow these procedures, or I'm the XXXX of IT, why do you think you can just buy that $99 component yourself and get reimbursed instead of doing this and this and this? None of those people are NEEDED to do the project, but they'll all be offended if they're not included or, worse, the processes they've created aren't followed when doing the project aren't followed.

This also tends to manifests at meetings -- meetings with more than, say, 7 people can de-escalate from let's talk about only what needs to be said for this project to let me say what I need to say so that I can show that I know what I'm talking about or that I look good for my boss or my department isn't irrelevant or one of 100 other things that genuinely have nothing at all to do with actually improving or helping the project itself.

There are ways to get around this -- meet with the individual stakeholder groups individually, don't allow large meetings to happen if at all possible, get the highest buy in you can from the beginning, forge key relationships in each department so that you have go-to people for getting stuff done, but honestly I'd rather just work in a small company because I can just do stuff and get it done extremely quickly (and small companies have these same problems too, they're just much easier to get around if you have the right backing -- you're trying to get around a department of 2 that's trying to roadblock you instead of a department of 50).

</comment><comment><USER37> Big orgs tend to rely on economies-of-scale and not nimbleness: they study the process and "regiment-ize" it to make it efficient by partitioning and standardizing labor, tasks, and parts so each part can focus on and perfect their particular corner of the world. Lack of nimble-ness is not necessarily the same as being less efficient.

However, regimentation can become less efficient if it gets in the way of change, and big orgs are known to be slow to change.

</comment><comment><USER38> I have worked at many companies ranging in size from small two person startups to massive megacorps (Hewlett Packard, Salesforce). One big difference I saw was that, in a small company, everyone succeeds or fails together. Everyone wins or everyone loses. This creates focus on shipping good product, not getting promoted over other people or competing for a bonus pool for the top 10% of the team. Larger companies have numerous structures and methodologies that decouple this and create many paths to "winning" that have nothing to do with shipping anything of value. You can completely fail to do anything and still get promoted. There is tremendous internal competition and politics, fighting over budgets, hiring, resources and power plays of all sorts. I personally got huge bonuses for literally doing nothing as managers and teams optimized around the internal political structure rather than any kind of product strategy.

<comment><USER39> I think this is really the heart of it -- if you're working on a product together, all you have to worry about is whether your work is improving the product. You can get other people to help you as long as it also helps the product. It's a lot easier to be productive when you don't have to worry about whether team X will be on board or whether executive Y will like what you're doing.

</comment></comment><comment><USER40> Efficiency is relative. The bigger an enterprise becomes, it becomes more important for you to consistently deliver in a defined timeframe and cost and have controls to prevent inconsistency, fraud and abuse. A smaller company will be more agile, but usually does so with more risk. For the markets they serve, that risk is often a competitive advantage, and things like pivoting and adapting rapidly are part of the process -- you cannot pivot and adapt without human agency.

For a huge company, consistency is key. The brake pad for a car must meet the specification. Falling below spec leads to waste, and producing over spec leads to cost and lost sales. In that context, manufacturing seeks to remove as much human agency as possible and follow the defined process.

This is similar in software. Some stereotypical cobol/java programmer in a bank/government building to spec is translating business jargon/requirements to code. The process of delivering the correct calculation in a predictable timeframe is the goal. Creativity, etc is usually a distraction best avoided, because the organization literally doesn't care about anything but delivery in the time/cost box.

Most big orgs separate operational teams from solution development and build. In some cases all operational stuff is outsourced. In these places, those non- operational teams get to be more creative, but are usually constrained by enterprise standards/solutions.

</comment><comment><USER41> Risk Aversion.

The smaller companies (aka startups) will do most anything to get customers. At some point in size when they become larger entities they will do almost anything to not risk losing business. Make changes fast turns into assessing the risk with every change and not wanting to cause problems. This slows down delivery.

There are also organizational factors at play the larger a company gets. You start getting teams having sometimes opposing goals set by the company. That is basically because of bad management.

Micro management also becomes a factor, there are too many personalities at play in a larger organization to quell this. Somebody will be the checker of all things and sole decider as a manager. This will morph people reporting into that person as risk-averse and decision-averse. They won't think for themselves and will wait to be told what to do.

None of this has anything to do with how complex or large a code base might become. It has nothing to do with technology. It is just an outcome of how large organizations are run. Upper management wants fiscal efficiency which usually means slower delivery and miscommunication.

I've been on smaller teams inside of a large mega-corp that were able to operate like a startup. They were managed very well in the sense that upper management "left them alone to do their thing". Then over time, the smaller teams were absorbed into a larger micro-managed entity who wanted everyone to do everything the same way.

</comment><comment><USER42> _One thing that has struck me is that, in my opinion, smaller companies seem to get much more done per engineer than bigger ones_

This may be true but you are not comparing like with like. No small company is going to use agile methods to build a dam or an airliner or a nuclear power plant or a chip foundry. Small companies are adept at doing trivial things like websites. Big companies can take on projects longer than the career of any individual.

</comment><comment><USER43> From my experience, larger, established businesses care very much about risk mitigation. Legal is a huge component of large businesses.

Fixing and maintaining software can not only cause bugs but may open a business open to serious legal problems.

So maybe a small change goes into production, and there's no problems reported; everything is fine.

Well you find out later down the road that Cambridge Analytic was siphoning off data from a properly working API deployed months before. No engineers were at fault. No problems reported in production. But also there was no legal analysis of the feature nor of the deployment in production.

Again, it's about risk. The more users or money flowing through the system the higher likelihood you're opening up the business to potential legal risks.

Big or small changes to a system used by big businesses must be carefully analyzed for potential serious negative financial impact on the business; from a legal, business, marketing perspective.

It's much simpler for a startup with a fraction of the users; because, again, they are exposed to less risk.

Either way, it's a great question.

</comment><comment><USER3> You have to count all the failed small companies too to make a fair comparison. All the man-hours that went into them is massive inefficient waste. Big companies manage risk more carefully and I think that's why they take more work to do that same thing. For instance, I sometimes the change the pricing of my small business based on just a feeling. It takes hardly any time at all. But if Microsoft changes the price of Windows, I'll bet there are lawyers and accountants and everything working on it for years, not to mention all the technical work and high level decision making. Seems inefficient but there's some chance my price change will destroy by business because I forgot something important, broke a law, didn't understand my market, programmed the buying page wrong, or whatever. Whereas, for Microsoft, they probably won't get sued out of existence for putting the decimal point in the wrong place because everything's mistake-free.

<comment><AUTHOR> This is actually a very good point I didn't think about. By virtue of their size bigger companies tend to have higher stakes, which means less margin for error.

I do wonder though how there's still large failures at big companies: security breaches, legal problems, DOA product launches, etc. I guess egos and oversights are just hard to completely sideline.

</comment></comment><comment> angus-prune While it is true that large teams are often less efficient than small ones, for many good reasons given above, there is another aspect to consider: Consistency and survivorship bias.

This only becomes clear when you compare a big company to _many_ small companies rather than just the succesful small companies.

80% of small companies fail in the first few years[1]. This is for a bunch of different reasons, but a significant proportion of the time it is because they have launched a wrong product, or a bad product, or failed to launch a product.

Lets assume that 50% of small companies fail for product related reasons [2] (the other 30% being competition, regulatory etc etc).

We can all think of high profile products from large companies that were still born or cancelled before being launched. If a large company had 50% of its projects fail like this, then it wouldn't survive for long.

To prevent these failure numbers, the large company introduces inefficiencies. Engineers or teams can't run off on their own and develop the 50% of projects which fail. Instead they have to jump through approval hoops so that the failure rate is much much smaller.

So even if an engineer is 50% as productive at a large company, they are actually as productive, on average, when you consider that 50% of engineering time at small companies is ultimately not productive.

As an ecosystem, large companies may not be that much more inefficient than small companies as a whole, they are just optimised for consistency, rather than risk and quick failure. Whereas the inefficiencies of small companies are externalised as failed companies.

The other side of this is that the potential rewards are often smaller - they're making a lot of small bets rather than a few big ones.

[1] my ass, but the close enough for this comment [2] ibid

</comment><comment><USER44> Two reasons in my experience: first, reproducability gets orders of magnitude more complicated as you grow. One person can do something over and over with no documentation, a few people can learn from them, but once you get to 10 - 20 staff in a role and you have some churn, you need good documentation, training, and QA since your risk for errors goes up no matter how good the documentation and training is.

Second, as others have mentioned is coordination. Now introducing a new process, feature, or whatever to clients or internally means creating the requirements, the documentation, working with sales or client services on timing and release, working with QA on test scenarios, working with training to get it into training programs, etc.

</comment><comment><USER45> It's important to ask the right question, to get the right answer.

One thing to wonder is if it's at all important to measure how much gets done, 'per engineer'. How can you possibly measure that and why bother?

One can be very productive, at doing something nobody will ever use. Another can be 50% as productive, doing something that'll be used by billions of people. One can be miserable and productive, another can be happy and 50% as productive.

These things matter - individual productivity in isolation, not so much.

By narrowing your question down to single individual performance, you've eliminated the possibility of getting a meaningful answer, other than 'revise your question'.

</comment><comment><USER46> Any size company has economies and diseconomies of scale. Very large companies tend to be very robust -- they can withstand a very wide range of conditions and pressures. But the cost of robustness is sustained complexity, to carry around many systems in case you might need them, whether you wind up actually needing them or not.

This is not unique to businesses. It's true of any self-sustaining system. Bacteria are _vastly_ more efficient forms of life than humans on many criteria, but an individual bacterium is much, much less robust to varied conditions than an individual human is.

</comment><comment><USER47> Throwing in my 2c as I've worked at massive fortune 100 companies and took a shift to work for small businesses.

The top comment about you eat what you kill in small business is the mantra. It's frightening to think if you don't perform, the risk isn't about not getting a raise, it's the company going under/firings will happen, now you need a job, other very bad stuff. This pressure forces you to be efficient, slacking off isn't an option and would be quite visible. Shit wouldn't get done.

Working at the large companies this was never a fear, if you performed above average (even probably average) your job was likely safe. The cost to hire, train, get someone plugged into the ridiculous amount of systems, assigned hardware, you name it is very high. Benefits are generally better as well because economies of scale, neat discounted stock options, etc. This probably opens the door to less efficient day-to-day stuff taking place (sometimes).

It's not cut and dry though, but I'm glad to have experienced both and am always open to either. Startup culture right now is super appealing personally because the whole Jobs' "Be Hungry" thing, age, mobility, etc but I'd imagine once you have a family to take care priorities and risk analysis is recalibrated which is cool too. Please note that I'm not saying having a family or working at large corporation the worker is less efficient it just might have less ramifications because of the structure.

</comment><comment><USER48> Big companies are inefficient because too much is at stake! A zero-revenue startup can publish an ad, and if it is offensive to the point of trashing the brand, literally nothing was lost. A big company could lose billions of dollars from the wrong kind of publicity. So there are 200 checks and balances in publishing an ad, making it take 200 times as many people and slowing down the efficiency of everything.

<comment><USER49> Is also to some extent a survivor fallacy: big firms are small companies that have survived and grown, failed small companies don't get to be big. By not accounting for this factor we deprive our model of a driver.

</comment></comment><comment><USER50> There is no one answer to this questions, and efficiency isn't always in the best interests of a "big company". Efficiency always must be tempered with risk. In startups, risk is embraced and therefore they can be very "efficient", but in many large corporations (and the federal govt. especially) risk must be quantified, controlled and eventually managed.

When you combine risk management with certain corporate cultures and market verticals, you get a combination of the following:

Risk aversion

Lack of technical knowledge in the management layer

Technology viewed as overhead vs. a value provider

These three things are deadly to an ambitious corporate IT project. Unskilled management can't appreciate requirements, manage scope nor understand trade- offs very well. The business wants guarantees on budget and timelines. Budgets are fixed, and management rarely wants to ask for more since ROI may be hard, if not impossible to quantify.

So what do you end up with? The standard "over-promised and under-delivered technology" solution that are endemic across so many enterprises.

[edit - formatting and spelling]

</comment><comment><USER51> 1\. When you do lot more yourself, there is a risk of burn out, risk of breaking something and also small teams have the luxury to fail fast and deploy more frequently which enterprises dont dare to do and now with more CI/CD guidelines enterprises are getting there to iterate faster.

2\. Small teams have the luxury to communicate faster and less noise when communication happens. Less heads involved in decision making , also problem of hierarchy of chains to pass through before something is started.

3\. Enterprises sometimes under-estimate the power of development environment setups. I know you might wonder why this point is here but if developer has luxury to setup environment quickly and efficiently without spending time on setting up dependencies lot gets done faster.

</comment><comment><USER52> Many large companies don't realize there are other groups working on the same project. This means you may see two teams of 6 people working on the exact same problem. Resources are then split, potentially this actually makes both projects fail.

</comment><comment><USER53> Scar tissue. It was something essential to stop loss of life at one time, but now it only consumes. This is a federal and academia problem: if you use less money this year, your budget is cut next year, so whether or not you need it every department finds a way to spend every single penny.

Needs of the organism change. It isn't like "slight" it is day and night. It is the nymph-been in the honeycomb-cell versus the working worker-bee. But fear wins. What if we still need the old.

And the paradigm of successful business is "don't break the goose that lays the golden egg, so change is very very bad".

</comment><comment><USER54> Sometimes I assume everyone in the industry has read Fred Brooks, but that can't be true, so allow me to quote some of him. This from a review of The Design Of Design:

Quality should be the responsibility of one person

One of Brooks's many excellent points is that quality happens only if somebody has the responsibility for it, and that "somebody" can be no more than one single person—with an exception for a dynamic duo. I am surprised that Brooks does not cite Unix as an example of this claim, since we can pinpoint with almost surgical precision the moment that Unix started to fragment: in the early 1990s when AT&T spun off Unix to commercialize it, thereby robbing it of its architects.

More than once in recent years, others have reached the same conclusion as Brooks. Some have tried to impose a kind of sanity, or even to lay down the law formally in the form of technical standards, hoping to bring order and structure to the bazaar. So far they have all failed spectacularly, because the generation of lost dot-com wunderkinder in the bazaar has never seen a cathedral and therefore cannot even imagine why you would want one in the first place, much less what it should look like. It is a sad irony, indeed, that those who most need to read it may find The Design of Design entirely incomprehensible. But to anyone who has ever wondered whether using m4 macros to configure autoconf to write a shell script to look for 26 Fortran compilers in order to build a Web browser was a bit of a detour, Brooks offers well- reasoned hope that there can be a better way.

[http://www.smashcompany.com/technology/quality-should-be- the...](http://www.smashcompany.com/technology/quality-should-be-the- responsibility-of-one-person)

</comment><comment><USER55> Think of a product as a graph where each component of the product is a node, and each other component or aspect of the company that it affects is a connection to another node. In most cases this means a graph where each node has many connections, so as the graph grows the growth of connections dramatically outpaces the growth of nodes.

As engineers on a product, we like to look at the nodes, but the business reality is often all about the connections. Want to make a change to a node in a simple 4-node graph? No problem. Want to make a change to a node in a 400-node graph with thousands of interconnections? Problem.

And that's why things slow down. Scaling a company is all about maintaining that graph so the connections are understandable and manageable, the connections are very well-defined (but not so defined that you can never change anything) and that you have the infrastructure in place to make changes and easily validate that there are no horrible side-effects.

</comment><comment><USER56> This may be a wrong mental model, but I view it as overall cost to maintain a structure. For example, the number of nodes (volume / support) to build a pyramid of height H scales non-linearly with H.

Height is not the same as output (and H / V is not the same as efficiency), but this model has some similarity to the real world engineering output. Just my 2c.

</comment><comment><USER57> I think the opportunity exists in the business world because when companies become successful is when collective leadership becomes most focused on maintaining success.

Usually, leadership tends to see more risk in the downside of the current plan and than upside in taking on new things.

Few things companies doing regularly:

1\. View a temporary trend as a competitive advantage. 2\. Focus on building reputational momentum. 3\. Believe it's easy to span across generations. 4\. Love being right. 5\. Love the new idea, not new way of thinking. 6\. Love being "Data-Driven"

Being right and staying right is totally different. Doing well reduces the incentive to explore other ideas, especially when those ideas conflict with your proven business model.

LINK: [https://allenleein.github.io/brains/2018/04/strategy-to- mast...](https://allenleein.github.io/brains/2018/04/strategy-to-master- theodds)

</comment><comment><USER58> I know what you mean. But appearances can be deceptive. How are you measuring efficiency? While at a big company it may seem to take more people more time and effort to move the wheels, the wheels are much bigger and they have much bigger effects. Look at the revenue-per-employee numbers for some large tech companies: [http://www.businessinsider.com/tech-companies-revenue- employ...](http://www.businessinsider.com/tech-companies-revenue- employee-2017-8). (Not shown: Netflix, whose numbers should probably be up at the top of the range). Ignoring the top end outliers, those guys are averaging around $0.5-1m. If the company grows by 10%, that's like having every ten person team bring in $5-10m in business through established channels, _and find a new $0.5-1m revenue stream_ every year. That's pretty efficient.

</comment><comment><USER59> You can't generalize but most often that is the case. Having said that I'm surprised nobody brought up maybe the most important factor: sunk investments.

If you have a brand name and credibility at stake, if you have customer liability, if you have built significant the features and infrastructure, if you hired the people that run and maintain those, if your revenue depends on current status of your product... We can keep going on but, you have to take extra actions and caution as you introduce change. That means additional complexity.

However keep in mind big companies can benefit from certain types of barriers to entry such as regulation that provide them efficiency over small companies. For example US immigration policy favors big companies, and IMO GPDR will do so as well.

</comment><comment><USER60> Big companies are efficient. At producing the product/service that they produce.

They've been relentlessly optimised to be really good at that one thing (or that one small range of things). There have been people touring the facility and cutting out slack for years to get it there.

Engineering is change. Changing a super-optimised process without degrading its performance is difficult. Way more difficult than building a brand new process.

Everyone involved in the project outside engineering is targeted and focused on optimising efficiency for the thing. There needs to be a lot of arse- covering and politics for them to accept that the thing needs to change, and accept the changes. Hence the accepted changes tend to be iterative and pedantic, not risky and exciting.

That's how I see it anyway...

</comment><comment><USER61> Big companies are amazingly efficient, just not in terms you consider. They earn way more dollars for each dollar spent than smaller companies. They can do that by having income sources beyond wildest dreams of smaller companies. That's the reason they got big in the first place.

And why from the point of view of footsoldier things don't look as efficient as they could be? Because they don't have to. Because inefficiency you see is negligible and trying to eliminate it could cost more money than it's worth. Heck, some income streams are larger if you work slower than you could. You could be harming your bottom line by making things more efficient.

</comment><comment><USER62> I see the increase in policies and procedures as a big issue at larger companies. Take your standard CRUD app created at some large corporation. It will go through QA, security auditing, legal, and whatever other team has established a policy or procedure around some process. Each one of these elements takes some number of weeks or months, and each different silo is typically unapproachable (or has some procedure on how to approach them, too).

Smaller companies can achieve higher velocity because the employees dont necessarily need the policies and procedures, or they simply havent been created yet.

</comment><comment><USER63> It's built into the design of an organization. It has a strong parallel to the natural world and how larger creatures have a slower metabolism.

The main feature that defines a really big company is that it is making something useful out of the labor of huge numbers of people - that the business model has become in some way premised just on recruiting more bodies and giving them a job to do, and that the company can keep generating jobs and see an overall benefit to its bottom line. If we posit that all successful companies are leveraging some mix of business structure against the labor and goods markets, a big business is clearly trying to leverage labor quantity, vs labor quality.

This becomes reflected throughout the organization with "industrial" best practice: lots of red tape and guard rails, practices that lead to overlapping roles and redundancies, an excess of meetings, brute force effort used to solve many problems. Like an overengineered, overpowered, overcomplicated machine, it works and it makes big products that nobody else can, just not with the kinds of visible efficiencies one might hope for. At the biggest end of the scale you get projects like the Apollo missions(great success!) or the F-35(they tried).

On the other scale, the individual, the labor quantity is vanishingly small. If you're sick that day, your output is probably zero or negative. But the ability to switch direction and try new routes and deliberately leverage skills and interests only you have is unparalleled. No "best practice" is needed, flying by the seat of your pants and doing things in a "wrong" way may well be the best way for you to go. And that's the kind of thing that defines little startups - doing things that aren't standard and don't scale.

As a coder it has some strong implications for which projects are worth taking on and when, too. Sheer feature quantity and complexity and mass consumer scaling vastly favors the "industrial" approach of putting large teams to work solving every problem by sheer force of will. Innovative designs optimized to human scaled limits, on the other hand, tend to favor the talents of a single human. And it can be hard to get a grasp on where you actually have leverage because so much of the visible landscape is defined by bigger projects with more bodies to throw at problems. They may move slower per programmer but they have more going on as a business - more sales and marketing, more in-depth research, more support calls, more deep technical issues caused by scaling, compatibility, legacy code. You can go really fast by simply solving a smaller problem on every axis - one customer, one feature, one deployment.

</comment><comment><USER64> I can contribute a few factors I've observed working at my Large Company of Choice (starts with a G). Personally, I believe that, in the ways that matter, engineers at larger companies are _more_ efficient than their friends at smaller ones, while simultaneously getting _less_ done. It's basically a "throughput vs. latency" problem: your work has a larger impact, but you don't see that impact for a very long time, so it feels less productive:

* Existing codebases need to be maintained. Small companies tend to be younger, which naturally comes with fewer existing systems that require maintenance, and those systems that do exist are generally smaller. The time spent keeping a large production system up and running feels wasted, but it's absolutely not, especially when you consider the alternative is letting the thing fall over and losing the revenue, users, etc. Contrast this against a smaller company where more projects are fresh and satisfying to write.

* Lots of work centers around adding features instead of greenfield projects with no history. Most of the code is already written, much of the infrastructure is already in place, and oftentimes the problem is similar to one that was solved previously. You end up writing less code to get more results, as opposed to a greenfield project where you write tons of code to even arrive at a baseline.

* Larger companies almost certainly have more irons in the fire than smaller ones. While on an individual level it's annoying to have to wait for input from someone who has half a dozen projects on their plate at once, on a company level this makes sense: when you have to put fifty features into production, you don't organize each one individually, you create a pipeline composed of people and run your work through it.

* As a result, projects at larger companies have more stakeholders, which means you need to get agreement from more parties before you can move forward. Also, you're likely not the only thing on those peoples' radars, meaning you'll have to fight for their attention.

* Larger and older companies tend to encapsulate their lessons learned into this pipeline. I'll hazard a guess that this is what people mean when they talk about "institutional failures" led to damages like Well Fargo or Facebook/CA, etc: no individuals failed, instead the system put into place to pipeline their work was faulty. The "human pipeline" of a larger organization was almost certainly built up in response to a long series of nonpublic failures. More quality in the form of fewer such failures, at the expense of higher latency.

* Politics is a thing. Larger companies almost uniformly have career ladders, with the aim of giving people a way to advance their career besides "take a CTO position somewhere else and come back at a L+1 18 months later." This means at least some of engineers' time will be spent marketing themselves for promotion rather than writing code. This often means choosing and prioritizing their projects by biggest expected impact. This has consequences if that engineer is a stakeholder in some other engineer's project and they disagree on the importance of that project to their respective careers.

* Finally, there's a human component to this. In my experience, the sorts of people who join smaller organizations and get tons of work done tend to be younger and less tied down. You're not going to be working at a 6-days-a-week 8am-8pm startup with a wife and children. You're going to be looking to put in your time and head off to live your life. Meanwhile your management is still going to demand big things from you, so you end up becoming efficient out of necessity.

I'll leave you with the upside to this so you don't come away thinking large organizations are hellish slave pits: The impact of your work is larger simply by virtue of your being at a large company. I won't go into details, but I work in a group that puts in months of work to move revenue by shavings of a percentage point here and there. When you finally launch, you end up thinking "man, all that work for a 0.5% improvement?" when in reality the baseline of that improvement is _staggeringly_ large.

</comment><comment><USER65> Big companies take care of details that take time.

Every few weeks I have some form of training. Diversity, reminders to obey copyright law... There is a fair number of things that I could screw up, a small company hopes I won't - or at least I won't get caught. A large company will change any bad behavior before there is a problem.

</comment><comment><USER66> I'd go by the Mythical Man Month. The communication overhead increases with more people vs the work getting done. That was my experience in my last company when we got acquired as our team sizes went from 5 to 15. In hindsight would have been better to split the teams to do different projects instead of one big project.

</comment><comment><USER67> Antecdotally in my experience there is also the fact that in large companies some functions no longer need to exist. That being said you have leaders who arent going to volunteer this and lose thier power or job so they clamp down and create middle management holds such as bureacracy or fierce protection of a function etc.

</comment><comment><USER68> I think survival bias is a huge part of the problem of comparing these two groups.

You are excluding from your set the small organizations with less efficient engineers, because they can not survive with even one less efficient engineer.

Large corporations can survive with many more inefficient engineers.

Plus most of what everyone else said.

</comment><comment><USER69> I've thought about this a lot, and reached a conclusion that feels a bit novel... in that I haven't seen it written about much.

The larger the company, the greater the share of all the mental energy of the total mental energy is spent internally competing for position.

</comment><comment><USER70> Coordination tax.

<comment><USER71> Yeah, best way to think about it IMO.

</comment></comment><comment><USER72> Far from a complete answer, but here are a few factors I've observed, in several large companies:

Distribution of responsibility/culpability

Culture of deniability

Systemic defense of the status quo

</comment><comment><USER73> Because big companies usually attempt bigger projects, and coordinating bigger projects that require larger workforce is inherently less efficient?

</comment><comment><USER74> I've had a lot experience here and it's something that's bugged me quite a bit too. I've spent several years on this.

The top comment right now mentions the separation between the engineer and the people using the software. That's an excellent point, but in a way it's circular. The larger you are, by definition the more people there are in- between (or among) you and the folks you're trying to make happy. You can mitigate that somewhat, but more people means more interference. So in way, saying you're not close to the customer in big companies is restating the obvious. Big companies do badly because they're big. True, but maybe not so helpful.

There's another good one: focus. Startups that scale quickly have laser-sharp focus on what value they're delivering. They can be so focused that they almost feel like a cult. Big, old companies might have been that way once, but they couldn't maintain it.

Communication overhead is another one of the top comments. I think that's getting closer to it.

Disclaimer: I have book about this. It's called "Info-Ops" [https://leanpub.com/info-ops/](https://leanpub.com/info-ops/)

Let me take all of these great comments and boil them down to the thesis of my book: just like we normalize databases to minimize storage and maximize efficiency, there's a minimum set of information complexity that any organization needs to function. (There may be tons of ancillary information not needed day-to-day, but relied on infrequently). In my experience, even in small teams, the communication noise and overhead is such that you quickly suffer from all three things: psychological distance from those you're helping, lack of focus on things that are important, and tons of communication overhead involving meetings, tools, and various things that doesn't seem to directly accomplish anything useful.

In fact, this is a systemic problem. That means that good, intelligent people acting in good faith doing their jobs? Only makes things worse. So not only does the functioning of the organization get inefficient, the more people teach, meet, adopt practices, and other things to fix it? The worse it gets.

There's a lot more, of course. But the thing to remember is that _big organizations have everything they need to succeed_. The information is all there. The people are all there. They have the time, tools, and money to immediately do a better job. (I think is one of the saddest parts about it.) It's the organization and flow of the information that gets quickly out of whack. They know what to do, they just can't get coordinated enough to do it.

Sorry for the book plug. Happy to answer any questions you'd like that I'm able to. There's a lot, lot more.

</comment><comment><USER75> I find it's coordination between the sheer number of teams and layers of management that create miscommunication

</comment><comment><USER76> I think they are optimized for high throughput instead of low latency.

</comment><comment><USER77> Here's a post I wrote about my experience as an individual contributor moving from Google to a smaller organization.

[https://corbt.com/posts/2017/10/28/small-companies-and- the-p...](https://corbt.com/posts/2017/10/28/small-companies-and-the- presumption-of-competence.html)

TL;DR is that I feel much more productive in the smaller company, in large part because there were SO MANY stakeholders at Google that it took a very long time to decide on a course and move forward with it. I think that experience probably generalizes to most large organizations.

</comment><comment><USER78> Because they can afford it.

</comment><comment><USER79> _um_ Isn't someone saying: 'Don't be that preceptive', preceptive too ?

</comment><comment><USER80> Go do a stint at Amazon and you will understand. Executive management is insane there. For instance, executives will just lie and say they are in charge of the X team where X is something popular and upcoming. There will be for instance, 3 teams each claiming to own a part of the business. Then you have middle managers lying to executives about what they have accomplished and will accomplish. Executives are clueless. At the low end you have teammates all who want to know what you are working on so they can go tell management they are working on it and you are just helping. If anyone finds out what you are working on you have literally 1 day to deliver the project before someone either takes credit for it or gets it shitcanned.

<comment><USER81> Wow that sounds really nasty.

</comment></comment><comment><USER82> > Is it that the inherent size and complexity of a codebase grows > exponentially as people grow linearly with time?

That's certainly a large part of it, and probably a large part of why no one likes maintenance.

You also have more managers, who get where they are in no small part by avoiding risk, who can derail re-writes in favor of more patching of things, possibly leading to more long term code problems.

</comment><comment><USER83> This is a systems redundancy problem. We are not the only species to face this. Ant colonies also build in redundancy into their organizations. [https://uanews.arizona.edu/story/lazy-ants-make- themselves-u...](https://uanews.arizona.edu/story/lazy-ants-make-themselves- useful-unexpected-ways)</comment>


On Extensions, Userscripts, and Archivers - <AUTHOR> https://content.4chan.org/tmp/extensions.html

<comment><USER2> Stack Overflow has solved a similar problem using WebSockets -- most of their pages will automatically update (e.g, to display the presence of edits, new answers, and added comments) immediately using a socket.

<comment><USER3> Yeah, totally, and some time _after_ he implements that he should micro-ban anyone making too many requests for the same pages.

</comment></comment><comment><USER4> i would think the answer is fairly obvious. 4chan needs an official API that allows for http connects to remain open. this way extension and 3rd party application developers have something to write software around that doesn't impede the ability to serve standard page GET requests to web users.

<comment><USER5> HTTP is the ultimate API. Everything else is designed for censorship of 3rd party tools. (See twitter.)

</comment></comment><comment><USER6> The main problem seems to be revenue. With 4chan, you could probably do a unique form of advertising -- companies pay ~$100/cpm to NOT have their products or brand featured on any 4chan pages. :)

<comment><USER7> Lol, In all seriousness though I'm pretty sure they could still find regular customers without too much trouble.

Not to perpetuate any stereotypes but fleshlight / masculine enlargement products and so forth would be happy to advertise there.

<comment><USER8> I'd imagine that kind of adult product would perform pretty badly on 4chan. The audience is definitely not in buying mode when they're there, and it's not like most people are going there explicitly for porn, so they don't have the kind of "motivation" that drives that kind of purchase. Probably things like cool / novelty items would do better there, things that appeal to teenagers with not too much money.

<comment><USER6> I think a lot of people just use ad blockers.

<comment><USER9> I've not seen an ad on the Internet since 2006. Apparently I'm evil and I'm bringing down the economy. If that means fewer jobs in advertising I count that as a win.

<comment><USER10> Adblock Plus for FireFox has an option to whitelist non-intrusive ads.

</comment></comment></comment></comment></comment></comment><comment><USER11> Thats interesting. And 4chan had only one guy (moot) managing all of this makes it even more impressive.

By the way, some of the posters commenting on 4chan degrading morality. This is an anon forum and its just a reflection of our society! The Guardian summarized 4chan as "lunatic, juvenile... brilliant, ridiculous and alarming". Perhaps the best description for 4chan.

And remember 4chan gave us LolCats, Memes, Rage faces etc.

P.S. By the way, why did mods kill the other thread?

<comment><USER12> > And remember 4chan gave us LolCats, Memes, Rage faces etc.

4chan gave us a voice. We are now legion.

Shared culture, sure - but it showed us there was an "us" to share that culture among. Its real effects are much, much larger.

</comment></comment><comment><USER13> HTTP 304, Not Modified?

There's no accounting for an inconsiderate user base. This has always been a big problem for 4chan. I remember several instances where the site was effectively taken offline for days by a JavaScript virus embedded in PNG images that _required the user to follow directions in the image_ in order to spread.

<comment><USER14> That wasn't /b/tards being inconsiderate, just _mind-numbingly retarded_. There's been a few JS worms like that, and it's almost always complete morons spreading them.

<comment><USER13> The point being that if 4chan users are (on the whole, anyway) too stupid to not spread JS viruses, asking them to not poll the servers so much is certainly a lost cause.

Getting the extension authors on board is probably the best option, because there's only a few of them, and they are _not_ stupid. Stupid users don't have the skills to write broken extensions for themselves.

The only alternative would be (as others have said) to add auto-refresh JS to every page and thus bypass the need for extensions entirely. If the number of people who currently use these extensions is small enough, however, this could just as easily drive their traffic _up_ because now every user on the site gets the same functionality without doing anything.

<comment><USER15> If moot charges by CPM that could solve his cash problem....

</comment></comment></comment></comment><comment><USER16> We must construct additional pylons.

</comment><comment><USER14> Image preloading and autogif are fantastic features, so getting rid of them would be a net negative. Instead, why not have them be controlled by some client side js, so that images/gifs are only preloaded for the next 20 or so posts from what the user is currently reading? If the user stops scrolling, stop preloading. Preload the final 5 or so images to cover skip-to-bottom, but the vast majority of the preloaded images will not be viewed, and so should not be loaded.

<comment><AUTHOR> Most users' arguments to that are they open a thread, click preload images/expand images, walk away, and so when the thread is dead/they come back, they have all the posts, and the full resolution images (not thumbnails). And the image expanding is done through userscripts/client side.

</comment></comment><comment><USER17> "despite having a bunch of fast drives in RAID 10 and 64 GB of RAM, our image server simply cannot keep up. "

Wait, so he only has a single image server?

<comment><USER18> It's not like a site that forgets it's contents in 2min or less needs more than that.

<comment><USER19> It's not really 2 minutes, it's far more than that (a thread I watched lasted >1 day), but a LOT of content drops off the site every second.

</comment></comment></comment><comment><USER18> The key take away is: if you don't look at YOUR server logs, but relay on 3rd party solutions, you are missing the picture. By large.

That Google analytics "guess" was abysmal. Client side logging is fine to complement server side.

</comment><comment><USER20> Use WebSockets. Use Pubsubhubbub. Outside of that and reducing the minimum poll time, there aren't a lot of ways of solving this problem.

</comment><comment><USER21> Meh, I'm always super unimpressed when simple text based websites have trouble scaling. Everything that's highly requested should be available in memory, and it should be trivial to spit it out instantly.

I'm not a scaling wizard, but I'd guess 99/100 times the reason CRUD apps have problems scaling is because they are over-engineered, and there is a tendency to solve scaling issues by adding another layer of complexity instead of optimizing the root application.

<comment><USER22> 4chan is an image board. None of the content is there long enough to be considered "Highly requested.". And like half the posts have jpeg's and png's attached.

Besides, how does caching solve the "My bandwidth bills are killing my wallet!" issue?

<comment><USER21> Here's how I would scale 4chan. All static items served from s3/cloudfront. Posted images pushed to s3/cloudfront. (Or wherever filehosting is cheapest). These are all the high bandwidth items, all thats left is the text/html, which isn't that much work.

I'd argue that all of the text could be served from 1 nice box if you wanted to(multiple boxes make it more complicated but not that much more). Send the post to each box, add it to a table/indexes in memory and write the post to disk and backups for recovery purposes. Then either update and cache every page the new post affects, or mark the pages dirty and update and cache them the next time they are requested.

Done, all pages served out of memory super fast, what am I missing?

As far as bandwidth bills, most browsers observe cache settings and won't re- download what it has already downloaded. His complaint is about getting hit too hard serving the html/text not the images.

<comment><USER23> > _All static items served from s3/cloudfront. Posted images pushed to > s3/cloudfront. (Or wherever filehosting is cheapest)._

Congratulations, you just _massively_ blew out your bandwidth bill. The cheapest option is to host your static content yourself, _especially_ if you're serving over a petabyte of it per month.

<comment><USER21> It really doesn't matter where you host the static/image files, as long as it's completely separate from the application server and doesn't eat into it's resources.

<comment><USER24> > We've also seen our image server's RAID array go from being relatively idle > to getting absolutely slammed

Sounds like it is?</comment></comment></comment></comment></comment></comment>


GCHQ (UK's 'NSA') Forced secure email service PrivateSky to shut down early 2013 - <AUTHOR> http://www.readability.com/articles/0zehabaf

<comment><USER2> Significant discussion here: [https://news.ycombinator.com/item?id=6893947](https://news.ycombinator.com/item?id=6893947)

that submission is from a different source (itsecurityguru.org) so this one may have different details.

There's another version here: [https://news.ycombinator.com/item?id=6896127](https://news.ycombinator.com/item?id=6896127)

        The real story on the PrivateSky takedown
        (certivox.com)

And here: [https://news.ycombinator.com/item?id=6900267](https://news.ycombinator.com/item?id=6900267)

        GCHQ Forced Secure Email Service PrivateSky to Shut Down
        (ibtimes.co.uk)</comment>


Ask HN: Do you feel obligated to go to work happy hours? - <AUTHOR> I currently work in higher ed as a developer in SF but am thinking about moving into the private world. The thing that I like about my current job is I don't feel obligated to do anything extra outside of performing my actual work, and I like to have work/private lives fairly separate. Should I be worried if I'm the type of person to say no to happy hours? <comment><USER2> Well, this isn't Japan or Korea ... it's not quite the same career obligation. But it can vary widely among startups especially.

Where I work we moved our happy hours to be squarely within work hours (before 5pm) and other places I have worked have had very few after-hours events. Just be aware that startups or young companies that you may be attracted to may not be congruent with your wish to have a life outside of work. If the company attracts more people with spouses/families, then they will be a bit more respectful of your life.

Also: remember, if they are keeping a scorecard, judging you based on bullshit like whether you attend happy-hour outside events, you need to note this in your evaluation of them. Don't let it all be on you. It is on them, for creating idiotic acceptance criteria. From time to time you have to be ready to fire your boss (get a new job) for his being an idiot.

</comment><comment><USER3> After work, on my own time? If I feel like going, I'll go. Haven't ever detected a problem with that over decades of employment. I might make an excuse, I might just say "nah, I was planning on playing an instrument/watching movie/diddling myself", or I might offer no excuse at all.

During work hours and I'm paid for it? I go unless there's an actual reason that I can't. I'm being paid for it, and if an employer is going out of their way, least I can do is show up.

</comment><comment><USER4> I don't mind going to work happy hours, but since I swapped from being a backend applications developer to SRE, I've been a lot busier at work/having to work later hours. As a result, I've been the person saying no to happy hours.

I don't know if you should feel pressure to go. It helps develop office rapport, but I also feel like if you have good rapport with your team and your immediate manager, you should be ok. If there's upper management going to some of these happy hours, it might be wise to just pop in every so often to make yourself known to them.

</comment><comment><USER5> I go to less than half of happy hours or other team "outings."

That way I'm not cast as "anti-social" and I don't let people start to expect me to go to each one.

Useful excuses _cough_ lies _cough_

\- a simple, "sorry, I already have plans."

\- friend or family member in from out of town

\- oh, I've got <some exercise class or hobby> tonight

</comment><comment><USER6> Maybe it's different in SanFran/SV, and likely very different in trendy start- ups, but in my ~15 years of working in the private sector in big, medium- sized, and small companies, I never once was even invited to a happy hour after work.

One company (Intel) did have a bunch of "team-building exercises" where we'd go play laser tag, or go to lunch together when a coworker was leaving the team, but that's it, and all those things were held during work hours (and considered work time), and paid for by the company. There were complaints in some departments and groups about having to work extra hours in order to compete with other employees in the year-end ranking/rating, but I never saw anyone expected to put in unpaid time after work for merely socializing. I also never saw it in a bunch of other companies I worked in.

If this is something that happens at all in the US, I'd expect it with Silicon Valley start-ups, but I don't know because I've never worked at one of those.

</comment><comment><USER7> If it comes up within your first three months I would suggest maybe going but leaving after an hour just so you don't seem antisocial. I'm with you in that my time outside of the job is precious to me but turning down every invite might give the wrong impression.

If it's a regular thing like say Friday every other week I don't think people will care a whole lot if you skip but if it's an occasion where you just finished a project or you are celebrating with another company I would suggest going just so it doesn't come across as being rude unless you can come up with a really good excuse such as "I would but I kind of promised I would take the kids to see XYZ tonight at the theater".

Anyway that's my limited experience 2cents.

</comment><comment><USER8> No, I usually skip them. We have these party type things about monthly in the studio bar/lounge area as well as team-specific things sprinkled here and there sometimes, but I almost never go. Sometimes I'll pop up to the monthly drinks event to fill up a bowl with free chips and other snacks and head back downstairs. They are just too loud for me to enjoy, it is impossible to have a proper conversation with someone most of the time, and I don't drink alcohol so there's really not much reason to go.

</comment><comment><USER9> Yes I did feel obligated to go, they were always outside of work hours.

The worst part was: it was an awesome team.

But when I was working, I always have 110% - and by the end of the day I was tired.

I wanted to go home and relax - being in a crowded, noisy bar was the LAST place I wanted to be.

I felt it always came off as anti-social, but I was really just tired.

Events outside work hours and the associated obligation to go was my #1 annoyance about working a full time job

</comment><comment><USER10> I work at a big company in Silicon Valley. Our "happy hours" take place during work hours, usually from 3-5pm. However most people use it as an excuse to leave work early to beat traffic on 101/280 (but let's face it, no one beats traffic here). I'm 26 while most of my coworkers are in their 40's and 50's. I don't think anyone cares if I go or not.

</comment><comment><USER11> This is completely company and personality dependent. Unless you're a single digit hire at a very fratty startup, I wouldn't sweat it.

</comment><comment><USER12> Nope. I have a well-known history of avoiding any company function outside of company hours. Come 5PM, we're on my time, my rules.

I've gone out drinking/movie watching/pool playing just to hang out with co- workers, but those were not by any means company-involved events. Just things we did to have fun. And they weren't even remotely mandatory or expected.

</comment><comment><USER13> I've only been working 4 years, but I have attended 0 happy hours so far, mostly because I don't drink. There are going to be people like you, others who don't care if you join them, and yet others who'll try to persuade you to join.

It's way down on the list of my concerns as a dev.

</comment><comment><USER14> in my case, no. "i have a 10 month old" is an excuse that gets you out of nearly everything.

</comment><comment><USER15> Although no one every really pressured me to attend happy hours, I always felt I was under some obligation to attend all social functions. I think this stemmed from my fear of disappointing people—I felt anxiety when saying "No." But I finally feel more comfortable under my own skin, now that I'm in my late 20s.

Plus, bars are not conducive for my (addiction) recovery.

</comment><comment><USER16> Ugh. No.

Or rather, I don't feel obligated to attend all or even most of them. I do try to attend once a quarter or so as a way of expressing that I'm not above socializing with my teammates, just busy.

</comment><comment><USER17> What most people are describing here is, to me, an almost alien culture.

Where I work in the UK it's common to socialise after work with colleagues (I'd rather call them friends) regularly after work. It's not usually sponsored by the employer and we rarely talk about work or our workplace unless something noteworth is happening there. It's not just current colleagues either. People who have moved on in their employment don't cease being friends.

However, my cousin works in the USA (not SV) and has met with frustration in trying to organise after-work activities as people there do not seem comfortable socialising with their workmates. To me, that's a shame, but I can understand that some like to keep their business lives apart from their social lives.

</comment><comment><USER18> If you want to go, go. If you don't want to, don't go.

Now, if it's _during work hours_ , if it's some kind of "team-building exercise" or some such, then yes, you should go. On your own time, though? On your time you do what you want.

</comment><comment><USER19> In some jobs, notably temp jobs, I have been. I don't drink, and my refusal cost me a permanent position.

In other jobs there's no obligation to go, and the employers often understand, particularly when the jobs have very low pay.

</comment><comment><USER20> We're in Chattanooga.

Our happy hours happen once each month and I've never been pressured to attend even when external guests are expected.

They know I have kids and my commute can be a half an hour or so; they understand.

</comment><comment><USER21> I'd ask why you are thinking about making the switch. What is important to you? The companies I worked at in LA didn't even have happy hours.

</comment><comment><USER22> Hell no. I skip almost everything after work.

</comment><comment><USER23> no</comment>


Fred Wilson: Quirky and The Cone Of Silence - <AUTHOR> http://www.avc.com/a_vc/2010/02/quirky-and-the-cone-of-silence.html <comment><USER2> Noisy restaurants are no accident. Young people (who spend money) supposedly like places that feel "alive." Old people (who don't spend as much) hate noisy places and won't go. So, restaurants who want to fill up their tables on a Saturday night with young people drinking $12 martinis play loud music and avoid sound dampening decorations.

I'm not suggesting that the Cone of Silence wouldn't be a good thing -- I'd buy one! However, the way to attack the problem is social rather than technological. Imagine starting a grass-roots campaign to tell restaurant owners/managers that you hate how noisy their establishments are. Print stickers that say, "I wish this restaurant was more quiet" that could be stuck on credit card receipts so management would be forced to hear your message. There's no business model in this, though.

<comment><USER3> You know what you have to do when you're on a date in a loud restaurant / bar?

Get closer to one another.

SCIENCE!

<comment><USER4> Or you could just make a move saying that the place is too loud, and that "we should just go over to my place".

</comment></comment></comment><comment><USER5> I know the 'wow' factor is greatly lessened but I wonder if two sets of in-ear headphones wouldn't solve this problem easily. 20dB+ of noise isolation is not uncommon and the addition of bluetooth (or even a physical tether) to pipe sound between people would make conversation simple.

If I could get over the feeling that it would look incredibly out of place at a bar or restaurant I would pursue the matter further.

<comment><USER6> He states in the comments that something like that would be "too intrusive".

It's actually clear from the comments that he's become more fixated on the device he has in mind than in actually solving the problem.

</comment></comment><comment><USER7> The functionality could be implemented now with in-ear Bluetooth headsets. A small device with an array of mics would process and localize the 6 or so closest speakers and transmit the output via Bluetooth. One could also include some miss in the headsets to provide correlation data.

</comment><comment><USER8> I highly doubt the cone-of-silence as he defines it is possible either. What's more interesting is the Quirky site/idea itself. Quirky is like <http://www.halfbakery.com/> in action, so I guess it is fullbakery. I wonder why startups like that don't make it to HN. Do people not know about HN?

</comment><comment><USER9> Even better if it has three modes:

      1.)  Everyone else seems silent to you
      2.)  You seem silent to everyone else
      3.)  Modes (1) and (2) simultaneously

I'm also curious whether Fred originally wanted (1) or (2) more [assuming (3) is not an option].

<comment><USER10> I would imagine #1. You can control #2 on your own...

</comment></comment><comment><USER11> +1

Silence is the ultimate luxury right now, it needs to be democratized.</comment>


Google Android 2.2 on HTC Magic with auto app update? (Pics) - <AUTHOR> http://androgeek.com/google-android-2.2-plus-automatic-app-updates-spotted-in-the-wild.html <comment><USER2> I bet the carriers are interested in app updates happening over WiFi and through syncing with the desktop. They would rather someone else foot the bill for that bandwidth.

<comment><USER3> Most of my apps are tiny in comparison to the actual amount of data (map tiles, images, youtube vids, web pages, etc) that I download. Streaming music is another big drain. I don't think the apps are even a rounding error in the whole bandwidth picture.</comment></comment>


Ask HN: Why can't we get search results for our bookmarks? - <AUTHOR>

I've been struggling with this for quite some time and i have tried few plugins for chrome. What would i really like to see is when I search for something on Google to also get results from the bookmarks I have made using chrome (they are synced after all). So why can't we have this ? <comment><USER2> Build it and they will come...</comment>


Why I Still Use Vim - <AUTHOR> https://medium.com/p/why-i-still-use-vim-67afd76b4db6 <comment><USER2> As an experienced programmer, I'd never use any GUI based text editor to open large files. For rest of the programming, vscode/sublime are pretty cool to use than vim/emacs.</comment>


Hong Kong police move in to arrest pro-democracy demonstrators - <AUTHOR> http://www.theguardian.com/world/2014/sep/27/hong-kong-pro-democracy-march-breaks-into-government-complex

<comment><USER2> Nothing new here folks</comment>


Ask HN: Has anyone heard about steroids being used to treat Covid-19? - <AUTHOR> I heard an anecdote from someone that steroids have been used to successfully mitigate COVID-19 symptoms. I have no idea how credible it is, so I tried to do some research, but I didn't really see any literature either confirming or debunking it. It makes some intuitive sense, given that a big part of the disease is an exaggerated immune system response. But I'm also highly skeptical that such an obvious and cheap solution could go unnoticed by the world for this long, so I tend to think there must be a catch.<p>Does anybody have knowledge or references on the subject? <comment><USER2> [https://www.who.int/news-room/detail/16-06-2020-who- welcomes...](https://www.who.int/news-room/detail/16-06-2020-who-welcomes- preliminary-results-about-dexamethasone-use-in-treating-critically-ill- covid-19-patients)

<comment><AUTHOR> Yeah, shortly after posting the question I found this coverage of the same results: [https://www.sciencemag.org/news/2020/06/cheap-steroid- first-...](https://www.sciencemag.org/news/2020/06/cheap-steroid-first-drug- shown-reduce-death-covid-19-patients)

<comment><USER2> Yep dexamethasone is a very well known drug used in both human and animal medicine. Ironically it is used for breathing issues quite often in animal medicine so it isn't surprising to see it have some benefits with Covid IMO.

Also ivermectin (anti-parasite drug) is being tested with and without the addition of dex which is kinda interesting but only time will tell how the studies come out. But it is interesting. [https://www.sciencedirect.com/science/article/pii/S016635422...](https://www.sciencedirect.com/science/article/pii/S0166354220302011) has a little about the ivermectin as a treatment.

<comment><USER3> FWIW Ivermectin is not a steroid and discussion of ivermectin here is not relevant to the OP. Many other threads on this forum discuss ivermectin.

<comment><USER2> If you read my comment you should have seen I pointed out ivermectin is an "anti-parasite drug", not a corticosteroid as dexamethasone is. As for the relevance, the two drugs are being used in combination as a treatment in numerous studies and preliminary results seem promising.

</comment></comment></comment></comment></comment><comment><USER4> As others have mentioned, steroids are frequently used to treat inflammation. Steroids' impact on whether a person lives or dies because of COVID is usually minimal.

Unfortunately, this has led to a shortage of some steroids, including hydrocortisone. There are people with unrelated medical conditions, like a member of my family, that take it as a replacement for cortisol in order to stay alive.

We have had a pretty rough time finding a place that can actually fill the prescription lately.

<comment><USER5> Sorry to hear your family member is struggling with getting medications. Are you based in the US? Purely anecdotal, but I work in an academic medical center and there have been no issues with steroid shortages. If your family member is having trouble to the point of not getting meds, if they live even remotely close to one, they (almost?) all have pharmacies that can fill scripts and I believe hydrocortisone can be prescribed for 90+ days at a time.

Less anecdotally, I've seen several COVID based guidelines recommending mail- order scripts — they are less geographically constrained, pretty much always on time and can be filled for similar timeframes, no standing in line etc.

Hope things get easier for your loved one!

</comment></comment><comment><USER6> > But I'm also highly skeptical

Using steroids to stop inflammation in the lungs is as old as steroids. This is not a special discovery. It's being spun as "news" since anything related to Covid-19 sells news.</comment>


Prior votes influence future voters in social aggregators - <AUTHOR> http://seanjtaylor.com/post/57714926977/science-paper-on-social-influence-bias

<comment><AUTHOR> I think we've all seen this on HN: the rich (higher voted stories or comments) get richer. Furthermore, a few choice words by a well known commenter can dramatically change how a comment is perceived by the community.</comment>


College Is The Best Time To Understand Opportunity Cost - <AUTHOR> http://eyinghang.com/why-college-is-the-best-time-to-understand-opportunity-cost/

<comment><USER2> That's a strange example of opportunity cost, especially in the context of college.

Having finite money and having to choose what you spend it on is a very simplistic example of opportunity cost.

More applicable to college students and gets at the core of opportunity cost a bit better, I think: "Go to a hackathon/job interview/conference, or go to class?" or, for some students, "go to a party or stay in and study?"

</comment><comment><USER3> Interesting article, but I had to view source to be able to read it. People who browse with JavaScript turned off see a blank page on your site (at least on Firefox 25).</comment>