Hacker News Reader

Comment by ethbr0 | Hacker News Reader

>> on the other hand, any individual customer you dissatisfy creates zero risk unless it is a mega-customer, so customer satisfaction is just a concept on a dashboard to be trotted out at an all-hands meeting, tut-tutted about, and then forgotten about

From my exposure to GCP from the enterprise side, this rings true. The folks we worked with were polite, but seemed to be asking us about our needs as a one-off / outside the normal process.

With credit to the teams we interacted with, they were helpful and acted on our feedback (things like "As a customer, I need a dashboard that tracks my GCP spending"), but it was apparent this wasn't something they frequently did with customers.

"The maze is in the rat" is a great metaphor.

Execs want certain things ("Realtime visibility into all projects!" or "Stability!") but underappreciate the organizational opportunity cost in requiring them.

Is it more important to have perfectly tracked projects or projects which ship 20% faster?

And if the former, we all understand you're training your people to be like forever, right?

View on HN

The problem with the article is that every company wants to manage risk; turning risk into money is what a company, any company, does.

Now bigger companies have processes, hierarchies, etc. to manage risk in a distributed way, because well they are bigger. But guess what these companies also have? profits! revenue! multiple products/services that produce that revenue that can be then assigned down at the appropriate level of hierarchy that took/mitigated/managed the original risk.

Google doesn't. It's a single-product company with a single Profit Line and thousands of Loss lines and it's pretending to be something else. That's why they are so busy managing risk all the time; most of them don't have revenues to manage, aim for, use to be rewarded for.

Google is a monopoly, a rentier on the internet. They need to be broken up and repurposed to multiple, actually value-creating companies. If not for the health of the internet, at least for the mental health of its employees it seems.

(I would argue that Google's "free" products, like Android, are the worst thing that has happened to the internet; they cannot be broken up soon enough).

For example, it could be fascinating to see YouTube as a stand-alone company. Currently its revenues are masked under the "Google" part of Alphabet. It sounds like it's extremely profitable. It could be interesting to see YouTube perform as an independent entity on public markets alongside other media entities, rather than bundled into a "tech" company.

From what I've heard, and from the decisions Google keeps making regarding revenue sharing, ads, etc. YouTube loses them a lot of money due to video storage costs. I believe they even restrict the quality of uploads for some users now to combat that, but don't quote me.

YouTube is profitable.

IMO, anything older than 3 years should be on paid plan. Save the planet, delete your old YouTube videos

> In 2022, YouTube's advertising revenue accounted for approximately 11.35 percent of Google's total revenue. That year, the video platform's annual ad revenues amounted to 29.24 billion U.S. dollars, up from the 28.84 billion U.S. dollars in the previous year.

https://www.statista.com/statistics/289659/youtube-share-of-...

For context, the sum total of Google's capex last year (offices, data centers, networking, everything) was around $30B. Meaning they could spend (almost!) every cent of that on YouTube video storage and still come out ahead.

I agree with your larger point but you exaggerate too much calling it a single-product company. Here's a revenue pie chart https://i0.wp.com/fourweekmba.com/wp-content/uploads/2022/10...

Search is 58% of revenue but I'd still call it at least a 4 product company with the "other" products contributing a decent 11%.

Ads is 80% of all revenue on your chart (search ads + network ads + youtube ads).

If you want, you can stretch their products to ads, cloud, and play store. But ads are still 80% of the whole pie. More if one accepts that some percentage of youtube subscribers are only paying to get rid of ads.

I would consider Youtube and Search and AdSense as completely separate giant businesses.

They all were at one point.

Imagine if they can't sell ads. How are they making money? I don't think subscriptions, pay per use, or referral fees would work.

They're different because the funnels are different. If Bing were to eviscerate Google Search overnight, YouTube and AdSense (other companies showing Google ads on their pages) will still continue to draw in the clicks and the eyeballs.

No. If Bing eviscerated Google Search, then MSFT could profitably serve and sell ads on video content, so MSFT/Bing would immediately want to set up a video site, and lure content creators off YouTube.

And I would add that the non-ads businesses listed there are money-losers. Their cloud stuff is still in the red, and things like Android and Chrome and Maps are basically about ensuring that there are places they can put ads.

> Google is a monopoly, a rentier on the internet. They need to be broken up and repurposed to multiple, actually value-creating companies. If not for the health of the internet, at least for the mental health of its employees it seems. > (I would argue that Google's "free" products, like Android, are the worst thing that has happened to the internet; they cannot be broken up soon enough).

Yes! I agree with this entirely. Google is the behemoth of mediocrity, the McDonald’s of tech companies. All their products are good enough to deter competition and to keep feeding search, and not an ounce better. Humans and human attention are just grist for their mill.

> turning risk into money is what a company, any company, does.

I must say that's one of the most unorthodox description of what a company does I've seen.

How is a bread factory or a plumber "turning risk into money"? It sounds like you're describing an insurance company or a bank, not, you know a company like Google who produces free software & services to billions of people in exchange for monetizing their attention. Focusing on risk mitigation in a company is explicitly optimizing for protecting existing income stream at the expense of innovation, customers, and new income streams. It's not what "any company does": it's what uninspired companies who have lost their ways focus on.

It sounds like what a consultant used to "financialize" everything would say to solve Google's problems and slowly turn it into an intangible conglomerate like GE who is just the shadow of its previous self. But maybe this time has arrived for Google?

A bread factory takes on risk by holding the ingredients for bread (which might expire, and cost money to store), paying bakers to make the bread (who might get sick or do a bad job), and on and on. It takes on and manages these risks, and if it is successful it makes enough bread to turn a profit and if not it goes out of business.

That's kind of absurd as a construction. It may be literally true that a bread factory accepts various kinds of risk in the ordinary course of business, but it's plainly not the primary reason that a bread factory turns a profit. Does a bread factory that hedges its future wheat purchases with wheat futures have a lower expectation profit than one which does not?

You can think about arbitrarily risk-neutral enterprises that are profitable. For example, what risk is a residential REIT taking, especially one whose properties are all insured? By contrast, you can look at a business like a casino (or a catastrophe reinsurer), where it is legitimately the case that operating income is predominantly the result of risk-taking. But when you put the two side by side, there is not a huge difference in ROIC (Return on Invested Capital), which you might've expected if profits were fundamentally a risk premium.

Your question about what futures is weird. Yes? It does have a lower expected profit? But a mitigation of downside risk. You seem to think the answer is "no."

That's because the answer is 'no', unless there's an underlying reason to expect that the expectation price of wheat will be less in the future. The only impact to profits is the actual transaction cost of the wheat futures, which is de minimis.

Since this is what you think, you should definitely go into some kind of real inventory heavy business and use futures to hedge against all your inputs going up in price. It'll be a real competitive advantage for you, since you seem to think it's all upside.

A lot of businesses actually do hedge their inputs, this is not a crazy idea I've just come up with. For some industries it's de rigeur (jewelers typically hedge even the value of their inventory and WIP), in others it seems to be a matter of preference (jet fuel for airlines). That's perhaps the single biggest justifying reason for the existence of commodity futures in the first place -- because producers and consumers want to reduce price risk. Agreeing on a fixed future price achieves that goal for both parties. Why would either the producer or the consumer need to pay anything to reach such an agreement? Why would it reduce expectation profits for either party? The futures markets simply provide a low-friction venue.

I agree that lots of businesses do hedge their inputs! Just as lots of people buy insurance. Reducing catastrophic downside risk of something is indeed worth a loss of expected value. But insurance has negative expected value, just like hedging their inputs. If you believe that it's costless or near-costless to hedge your inputs, you should do it literally everywhere to everything that you possibly can, and anyone who doesn't is just leaving money on the ground for you to pick up.

And while lots of businesses do hedge their inputs to some degree, it is not the case that everyone does it to the maximal possible extent.

> If you believe that it's costless or near-costless to hedge your inputs, you should do it literally everywhere to everything that you possibly can

... no? Just because you've eliminated price risk doesn't mean you've eliminated holistic market risk. For example, suppose you're an airline: if fuel prices go up, and your competitors are not hedged, it's no big deal if you're not hedged, because everyone just increases ticket prices. But suppose you ARE hedged, and your competitors aren't, and fuel prices go down, and your competition cuts ticket prices, and... uh, you're screwed, because 1) you have a bunch of fuel locked in at the higher price, and 2) nobody wants to buy your tickets with the old fuel surcharges. So you're forced to take a loss, and the hedge hasn't actually reduced business risk in this scenario. It tends to depend on the game-theoretic context whether hedging commodity inputs actually reduces systematic risk.

Seriously, hedging price risk in commodities is nearly costless, decisions not to hedge almost never have to do with the actual cost of the hedge. In the real world where things are much more complicated than a toy example, many airlines do some hedging, with the aim of reducing sensitivity of profits to short-run volatility in oil, rather than trying to truly eliminate exposure to fuel prices. But that does come as a "free lunch".

"Does a bread factory that hedges its future wheat purchases with wheat futures have a lower expectation profit than one which does not?"

To the extent that it hedges them rationally, they have exactly the same expectation profit. But the bread factory that hedges its future wheat purchases has a lower real profit than the one that does not, assuming the price of wheat doesn't go up, because buying those futures contracts costs money. That's what it means to turn risk into money: if you are willing to bear the costs of things turning out poorly, you can avoid the costs of avoiding the chance of things going poorly, and increase your profit by the same amount.

I think in general the transaction costs associated with hedging wheat price risk are so small via futures (0.05% or less) that it proves the larger point that profits cannot possibly be due principally to assumption of risk.

"For example, what risk is a residential REIT taking, especially one whose properties are all insured? By contrast, you can look at a business like a casino (or a catastrophe reinsurer), where it is legitimately the case that operating income is predominantly the result of risk-taking."

If you actually believe that a residential REIT is zero-risk and a casino is high-risk but they have the same ROIC, you should buy REITs and short casinos and you can make a big profit. That illustrates why there's probably a flaw in your understanding (though not necessarily! you might be able to make a big profit!). The market should have the same logic, and if this is actually true, REITs will be bid up and casinos bid down until the ROIC on casinos is higher than on REITs, appropriately compensating investors.

FWIW, REITs face a lot of significant risks, eg. a regional downturn could lead to all the workers becoming unemployed and vacating or not paying rent, or a rise in interest rates could increase financing costs, or rent control might be enacted and prevent the property management from raising rents as much as financial models predict. And casinos are actually much less risky than assumed: most gambling games have statistical models for how much they pay out, and with millions of games played reality tends to approximate the models very closely (due to the central limit theorem), and they tend to take out insurance on extreme black swan events anyway. I don't know the ROICs on either of these industries in detail, but I suspect that if it's similar, it's because the actual risks to them are similar.

> If you actually believe that a residential REIT is zero-risk and a casino is high-risk but they have the same ROIC, you should buy REITs and short casinos and you can make a big profit. That illustrates why there's probably a flaw in your understanding (though not necessarily! you might be able to make a big profit!). The market should have the same logic, and if this is actually true, REITs will be bid up and casinos bid down until the ROIC on casinos is higher than on REITs, appropriately compensating investors.

No, the return on an investment security (in this case, a share of publicly traded stock) is different from the return on a dollar actually invested in the underlying business (i.e., ROIC). This has a lot to do with the price action that you outline.

The rest of your comment deals with why these are bad toy examples, which is fine but not really all that interesting in context.

The security reflects how investors expect the ROIC of the underlying business to change over time, hence the "risk" aspect. They're forward looking over the life of the security's cash flows, while the company's financials now are a snapshot in time.

You're still confused. The EMH is understood to imply that securities prices are the NPV of future cash flows (or more specifically their best estimate, using all public information), but that has nothing to do with ROIC.

(As an aside, the EMH is obviously false and you don't need to look any further than meme stocks for evidence, but anyway)

For example, suppose you have two businesses, both of them have a future cash flow NPV of $1 billion. However, one of them was started in a garage with $1 million of angel money. The other one is a "fallen unicorn" that got $500 million of VC money before it finally IPOed.

The ROIC of the first company is obviously going to be something like 500x the second, but this is irrelevant to their market caps, which should be the same in textbook-EMH-land, ceteris paribus.

This and the responses should be required reading for all the folks who claim that the free market requires perfect information. Well done!

Efficient markets require perfect information. Free market is nowhere near efficient.

> Efficient markets require perfect information

No, they don't. I'm wondering where people get these ideas.

From the definition, if you squint a bit at 'perfect'.

Making up your own definitions of things is creating a strawman.

I do not disagree with you, but that's exactly what the author of the blog post emphasizes: focusing on the "risk -> money" is an example of missing the forest for the trees. It's not the company raison d'être (unless you're talking about an insurance), you're just summarizing how a company operates under a very specific lens, the same way you could describe a company as something converting paycheks into human labor. A company makes products satisfying customers: that is its core purpose. Focusing on the process instead of the product is exactly why mega-corporations fail, which was the main point of the blog post.

The bread factory and plumber turn a little bit of risk into a little bit of money. A company like Google or Goldman Sachs turns a lot of risk into a lot of money, if they manage the risk so it pans out, or a lot of risk into losing a lot of money otherwise.

GP's description is actually quite astute. The legal concept of a "corporation" exists solely to pool risk and limit downside; it originally came from shipping voyages in the early age of colonialism, where a significant portion of vessels simply sank with all hands, but one successful voyage would make everyone involved wealthy beyond belief. Basically every business endeavor you do involves some risk, because the future is unknowable. The plumber might fall into the sewers and drown, the bread factory might be contaminated with E-coli and get shut down by public health after getting sued by all the customers it got sick. But certain endeavors, the ones like the plumber or the bread factory, have largely been studied, systematized, and structured to maximize the chance of success. These are low risk, but they're also low reward, because low risk invites lots of competitors. Other endeavors like writing complex software systems or predicting financial markets fail all the time, and that's why succeeding at them is so lucrative.

No, this falsely equivocates risk with innovation and just regular opportunity. It’s not a given that low risk with low innovation required will have high competition. This is especially true the smaller the market.

On the other end of the spectrum, there are very high risk businesses with no innovation and stiff competition (e.g. dealing illegal drugs).

Your argument is just about investment diversity, not about the purpose of a company.

> On the other end of the spectrum, there are very high risk businesses with no innovation and stiff competition (e.g. dealing illegal drugs).

This made me laugh out loud. I'd say drug dealing is one of the most innovative businesses around. At the high level, cartels are constantly inventing new methods of smuggling and money laundering. At a low level, dealers were first adopters for text messengers, crypto messengers, cryptocurrency marketplaces etc. I'd say this makes them more innovative than most startups (who often just re-invent traditional business but done online). Dealers even make profits!

Some dealers do some innovative things sure. But most are just use violence and local neighborhood knowledge to stay hidden.

“Using a burner phone” is a 20+ year old trope and it was pay phones before that. Not exactly innovation.

The people that made crypto currency market places were pretty innovative. The dealers that used them weren’t. They are the equivalent of people who discovered eBay in the 90s. Early adopters, not innovators.

If a market is sufficiently small as to be not big enough for competition, that strikes me as pretty high risk of becoming too small for any players at all. E.g., think of the main street of a small town. My mom lived in a town that had one grocery store, one gas station, one restaurant. All of them were marginal operations. And there were a lot of empty storefronts on the main drag, places that were no longer sustainable and had gone under.

> The bread factory and plumber turn a little bit of risk into a little bit of money.

Plumbers make excellent money, not a "little bit". I don't know about bread factories, but I assume they do well too.

It's relative. A good plumber with his own small business might make half a million a year. A bread factory probably makes in the low millions, if they're anything like the small businesses (eg. box factories, hot tub supplies, auto repair shops) I know. Google makes $60 billion, and Goldman Sachs makes $11B. That's 5 orders of magnitude.

Plumbers and bread factories make good money compared to salaried W-2 employees (even compared to Googlers, sometimes), but this again is a risk/money tradeoff. When you choose to work for a big company, you are trading off the risk that your efforts will be useless vs. a guaranteed payday that lets the company keep all the rewards if they're successful. In software it's trivially easy to make the opposite risk vs. reward tradeoff: just incorporate the company yourself and get acquired, in which case you get nothing if your efforts are unsuccessful but keep the full market value of your product if they are.

This is basic economics. Taking on risk in expectation of a reward sometimes pays money, sometimes risk becomes realized and you lose money. This applies to Google and your plumber in the same way.

> It's a single-product company

> They need to be broken up and repurposed to multiple, actually value-creating companies.

These obviously can't both be true. You need to take your pick of what you critizice.

Perhaps there's no drive for revenue due to these services being subsidized by the main income stream.

The real cost of delivering these services is written off by the company as a necessary expense. The value obtained from these services via goodwill or some other metric is currently deemed to be greater than their cost.

Google is famous for basically just ignoring customers. Or more accurately, ignoring users, since users are not customers.

Customers are those spending money posting ads on search. Frankly even they get crap customer support, but at least they are customers.

I'm no googler but it's clear "user support" (and "customer support") are not priorities at google, and that means other people _are_ priorities. So it's not exactly a shock to discover employees optimize to make other employees happy (measured) versus keeping users happy (not measured.)

I factor that in when I decide if I want to be more than a user, if I want to be a customer. (So far the answer is basically "no".) And, as a user, I understand I'm not a customer and Google doesn't care about me, or my gmail account... So I treat my gmail account with the importance it deserves.

So what though? This makes them happy, and they're all paid, so what does it matter what the outside world think or care?

I have been a enterprise customer of google cloud.

There is a chasm between google cloud and microsoft azure. Azure sucks as a product, but they really, really, really want you as costumer. Damn, I get a weekly one-to-one with the guy which was part of the team that created their kubernetes offering, just because I needed someone with expertise in the matter to help us maximize the benefit or ours. NO EXTRA COST.

With Google I got a guy that knows Kubernetes less than me. I sometimes get embarrassed asking them questions because they don't know how to answer but must come up with something to answer because the account manager is in the call. It feels like their poor account managers take a uphill battle just to get someone to talk to us. I feel sorry for them.

Guess what happens? must deployments are in azure, even if the azure CLI sucks, the azure portal is a mess and azure products are inconsistent.

But Google's GKE ingress takes 20 minutes to update (there is a years old bug opened, nobody cares), vs Azure application gateway taking 30 seconds. Both being very bad for us, but I get to talk to the Microsoft the guy who worked on that integration and discussing with him the pros and cons of using ingress-nginx instead.

Google don't want us as costumers, they just want to brag about having a better cloud (they don't).

(as a PS, please microsoft your employees don't like to answer questions on stack overflow. But great to be able to get stackoverflow answers from the product managers).

if you're on a call with an account manager and a support person, and the support person is clueless, politely shut down the meeting early, and then schedule a 10-minute with the account manager to tell them the support person isn't helping.

As much as I hate personal relations, I frequently have to "herd cats" (contractors and cloud vendors). On the other hand, once in the while I get an absolute superstar and I work to keep them on my projects as long as possible.

Yeah, this is what they can give me. Microsoft people offered us high profile people for free.

> Azure sucks as a product, but they really, really, really want you as costumer. Damn, I get a weekly one-to-one with the guy which was part of the team that created their kubernetes offering, just because I needed someone with expertise in the matter to help us maximize the benefit or ours. NO EXTRA COST.

When I was at Microsoft, the highest tier of support contract got you meetings with the lead developers of whatever product you found a pri0 bug in.

Found a way to crash the compiler and simple code changes weren't enough to work around it? A meeting with a member of the C++ compiler team would be arranged.

Microsoft has a history of customer focus, though I fear that was very much diluted when MS got rid of their dedicated test orgs.

How does that scale if there are many customers that need to meet the lead developers like OP get in weekly 1:1?

Sorry to hear about your experience thus far. I'm actually on the GKE team. Happy to find some time to chat and get you in touch with the right folks from the GKE networking team. DM me on Twitter at @garitweets and we can connect.

HN support forum in full force.

That's a new HN tag

I used to work for a big enterprise software company and believe me, their support is the same. Unless the issue is highly escalated, there is no way that the support engineers pay enough attention to it. I used to say, that the best customer is the customer who knows the answer. You are all by yourself most of the time:) But you have to pay support fees without any delays.

They don't seem to care about their corporate customers either. eg. corporate gmail spam filtering is fundamentally broken and no one seems to be able to do anything about it.

My companies have been google customers for years, have spent hundreds of thousands of dollars with them, they’ve never cared about us. Bad service and sometimes impossible to reach a person.

You are not a big customer to Google.

Ah-ah. I am sure even if you had millions of $ in support fees, they still won't care about you. You have to have pay more, get a dedicated accounts team and let them manage issues internally.

Millions? That's not even in the right ballpark for them to notice one way or another.

Google brought in around $284B in 2022, Big customers are at least double digits, so for Google, one needs to spend at least ~ 30B/yr to be considered a big customer to them.

I work for a company that has spent billions of dollars on Google ads in the last decade and it doesn't seem like we're a big customer either.

Sorry to break it to you, but you are not a big customer to Google either.

Let's assume that billions is actually 99B. So roughly 10B/yr. This is roughly 4% of their income in a year(~ 284B in 2022).

Big customers are at least double digit % of their income.

Source: trust me bro

    Is it more important to have perfectly tracked projects or projects which
    ship 20% faster?

It's far more important to have perfectly tracked projects. A perfectly tracked project which is guaranteed to deliver on a particular day is gold. It makes planning for the rest of the organization much easier.

To use a programming analogy, it's like the difference between latency and jitter for real-time systems. Many real-time systems will happily sacrifice considerable amounts of average latency, in order to minimize jitter. It's far better to have a process that completes in 200 ms every single time than it is to have a process that completes in 2ms most of the time, but, occasionally takes 2000ms.

Similarly, from a managerial perspective, it's far better to have a team that gives you good visibility, allowing you to plan for a completion date (even if that date is farther into the future than you'd like) than it is to have a team that mostly finishes projects quickly, but occasionally bogs down and takes a year to finish a project that was initially estimated at two months.

The problem is that far too many organizations have neither. They don't have visibility, and they finish projects late. For these organizations, your dichotomy is a false one — better tracking is how they will ship faster.

> better tracking is how they will ship faster

There's a reason PMs are reviled to mildly tolerated by engineers: they believe the map is the end product, not the territory.

The correct answer to which is more important is "It depends."

There are many businesses where shipping 20% later leads to ceding first mover advantage and losing the game. Largely what's being discussed in the article.

More detailed and accurate project tracking and projection doesn't deliver quicker shipping. Effectively prioritizing outstanding work does.

They're similar but definitely not the same.

    There are many businesses where shipping 20% later leads to ceding first
    mover advantage and losing the game.

Are there? Can you name some examples? Because when I think of technology, first-mover advantage counts for very little. The first successful web browser wasn't NCSA Mosaic. It was Netscape. The first successful portable music player wasn't the Nomad, it was the iPod. The Macintosh long predated Windows, but Windows has by far the larger market share. Same with iOS and Android. Google was far from the first search engine. Facebook was far from the first social network. Amazon didn't invent e-commerce. In automobiles, Ford was first to mass production, but it was overtaken by General Motors by the 1930s, and they both were in serious trouble when the Japanese auto manufacturers, which didn't even really get going until after World War 2, arrived.

So in which business exactly does shipping 20% later lead to "losing the game"? If anything, the real risk is in shipping a half-baked product too soon.

AdSense, Amazon, Apple II / iPod / iPhone / iWatch, CNN, JavaScript, Netscape, Netflix, PayPal, Roku

The critical window isn't when something is first possible (e.g. when the first product appears), but when the combination of technical abilities, component price points, and market characteristics intersect to permit success.

To use a physical example, the iPod and iPhone were great products, but they were hits because they launched with the features they did, at a specific point in time, at a specific price point.

We know that potential for success infection point existed then, because they did build a working device and achieved success.

Consequently, if they had not completed those devices when they did (say, +20% time), another device could have achieved their success.

Maybe nobody on the planet existed other than Apple who could do it... but the possibility was provably there.

Or in simpler form: Netflix was far from the first streaming video service. They were the one who launched with the right features at the right time.

Nobody cares if you catch a small wave perfectly. What matters is catching the best wave of the day, in the brief window you have.

The reason all those examples you cite became as successful as they did is because they spent that extra 20% to get it right. They didn't just ship some MVP out the door. They spent a huge amount of time and energy to get the product as close to perfect as they could before shipping. Steve Jobs, famously, became concerned about the aesthetics of the traces of the circuit board on the original Macintosh [1], spending $5000 (16,330 in 2023 dollars) and a couple of weeks, to have a circuit board created with better aesthetics. Then they threw that board away because, it turned out that aesthetic traces don't actually correspond to good signal propagation.

That's the reason that Apple, especially, has been so successful. It's not because they launched at some perfect time window. It's because they launched damn good products. If the iPhone had launched in 2008, or even 2009, it would have been just as successful. We just would have had another two years of mediocre Windows Mobile/Symbian OS/Blackberry devices.

[1]: https://www.folklore.org/StoryView.py?project=Macintosh&stor...

I think that's an oversimplification. The original Mac was a terrible computer. It was slow, it had too little memory, it overheated, it wasn't expandable, the keyboard was deliberately crippled by removing the arrow keys, it had a single button mouse, and it required almost endless floppy swapping.

The graphic UI and the case design were distinctive. But what really sold it was an incredibly sophisticated ad campaign that carpet bombed key media outlets with super-expensive exposure.

The problem with Symbian/Blackberry/Palm wasn't just mediocre technology, but a lack of dazzle. The products were functional but mediocre. But they were also marketed in mediocre geeky/corporate ways that just weren't that interesting to most consumers.

The original iPhone was barely more functional. But again, exterior aesthetics and a huge marketing and PR campaign forced open a consumer market for a product that was - like the original Mac - barely finished.

The problem Google has is that its products and its branding are heading rapidly towards mediocrity. It reminds me of DEC - an engineering giant in the 70s and 80s, which forgot how to read the market and innovate in the 90s, and crashed far more quickly than anyone would have predicted.

> Because when I think of technology, first-mover advantage counts for very little.

This. The ideal thing is to be second, or even third, not first. "The pioneers get all the arrows."

I used to think this.

But as a member of a small-ish company, I remember there was this time the sales VP insisted that we MUST have this product out by a certain tradeshow. Engineering worked hard and delivered, and although the thing had warts, it gave our company an advantage: the current market leader showed up at the next tradeshow a couple months later (e.g. "20%") with a similar product and price point, but our lead in time meant that we were able to exist as a strong competitor. This single product launch and subsequent sequels lifted our company for quite a long time.

So now when the sales guys insist we might need something by a certain date, I carefully evaluate rather than dismiss out of hand - I've learned to trust their role as well.

> Facebook was far from the first social network.

Oh? By this rule, then Facebook must have been quickly replaced by one of the many competitors who launched later, yes?

Quite likely, if the playing-field was level, or at least they'd have lost huge market-share.

Facebook bought Instagram in 2012 precisely because they were a direct threat. The FTC could have blocked that; or more recently, prevented tighter integration with FB+WA.

Currently they're using lobbyists to try to push TikTok (and WeChat) out of the US market.

Yahoo imploded because it had to pander to the short-term whims of the stock market; Zuckerberg references this frequently when talking about how FB (i.e. he) maintains control of its stock and autonomy.

> More detailed and accurate project tracking and projection doesn't deliver quicker shipping. Effectively prioritizing outstanding work does.

This is it. With the advent of broad, powerful tools you can use to automate off your codebase, there's less and less manual rote work that needs tracking, and a greater and greater percentage of creative, hard to estimate, engineer-driven work. And the best way forward is to plan releases with certain features, and flexible timelines, or plan releases with fixed timelines, and flexible features.

Tracking does not guarantee anything. Tracking only tells you have missed the release after all of your plan is already destroyed.

You seem to want estimation. And you will keep doing exactly that, "wanting", because estimation isn't something that scales to big projects or multiple ones.

We're not special [1]. Programming isn't that different from other engineering disciplines. The difference is that, somehow, programmers have developed this anti-intellectual attitude that keeps them from doing the hard work needed to develop the estimation tools that other engineering disciplines take for granted. Step one in developing those tools is tracking.

[1]: https://www.hillelwayne.com/post/we-are-not-special/

Major infrastucture and other construction projects are behind schedule and over budget constantly. So I guess I agree that software isn't that special, but I'm a different direction.

We are special in that nobody wants to spend the time to spec software in detail up front and we usually make major changes to requirements in the middle of the process.

If we had something like a detailed blueprint before writing a line of code and the requirements were set in stone we could get a lot closer to other engineering disciplines in terms of predictability.

With the kinds of planning and estimating processes we do actually use you’re lucky to get within a factor of two of reality.

The way I've heard it phrased is "If the physical properties of concrete changed every two years, civil engineering would look a lot different." (forget the source)

I think we're outliers in a couple of ways. One is what you mention -- we're usually both the architects and the construction crews of our projects, and we do both parts at the same time.

But there's also a step back -- how long does it take you to fully design, but not program, a particular piece of software? If you give a general contractor a particular set of blueprints, he can tell you roughly how long it will take to build, both the ideal number (if there are no scheduling or shipping delays) and what it probably will end up being. But if you tell an architect you want a design for a particular size and purpose and style of building, she can also tell you roughly how long it will take to draw that up.

How long does it take to design a particular piece of software? What makes a design take a day or a month to iron out, well enough that you can get a correct estimate of the amount of time it will take to build it?

I don't think we're good at that, as a profession.

> I don't think we're good at that, as a profession.

We aren't. And, as an industry, we have managed to convince ourselves that's a good thing. Agile methodologies, after all, are an attempt at making such efforts unimportant.

Yeah, we are not special. Estimation doesn't scale for any other kind engineering either.

true, but the comparison to other engineering disciplines does not hold up well at all: while everybody understands that planning when building a House is important as once it stands you can only change it at significant cost this does not hold true to software development. here we press a button and the house is constructed and with CD even delivered to the customer. my take: we ARE very special as our problems have not ever be encountered in the course of mankind due to the very nature of software.

It’s hard because a good portion of tasks which software developers need to estimate are not iid hence the law of large numbers doesn’t apply.

Nope, that blogspam article misses the mark by a mile. The major difference in almost all software environments is that the software requirements constantly change, even after the initial version is done.

Estimates in civil engineering are going to look just as bad as software if it was common to keep adding floors of different sizes to a building after it was complete followed by a “pivot” of turning the building into a support structure for a suspension bridge.

Software that is as rigid as tradition engineering projects in the real world can certainly be estimated, this happens in safety critical stuff all of the time. But the estimates are long, and requirements cannot change without massive delays, which is terrible for most software use cases.

You realize that this sort of requirements change happens all the time in construction projects, right? Granted there are limits to this, but the vast majority of construction overruns are caused by changes in requirements.

Requirements change in non-software projects but rarely do they change the project into a completely different category like "I know we started building an office tower and it's halfway done, but now the client wants it to be an airport." This happens in software all the time.

Do you know why construction projects don't get huge last minute changes very much? Because every change request is a billable event.

Software companies don't do this much. I've worked at only one that charged for changes, and -- surprise -- such changes were very rare.

Yup, in fact this is the strategy for profit maximisation for many, many construction companies. You look at the plans/requirements and if you spot loads of missing things you bid a low price with high prices for changes and make loads and loads of money.

Source: this is what my Dad did for a living, and I spent a couple of years doing it in my twenties.

It is also the strategy for profit maximisation for many, many software companies. "Change request" is a big deal in outsourced enterprise software dev. It is so bad that 'honest' software development groups that estimate accurately and don't have a culture of change requests cannot compete.

It’s still a change before it’s done and it’s pretty constrained. Scope changes too big are just completely impossible because of physical constraints, lack of permits, etc.

The requirements changes in construction projects are child’s play compared to the ridiculous stuff in software. “Oh, now that we have this data visualization app finished, please add in support for collaborative visualization exploration with synchronized views and voice chat.”

> A perfectly tracked project which is guaranteed to deliver on a particular day is gold. It makes planning for the rest of the organization much easier.

This is such a good example of prioritizing internal desires over customer needs.

> better tracking is how they will ship faster

My long experience is that heavy tracking is strongly correlated with slower shipping. Because tracking is treated as a substitute for actual domain competence.

It's worth noting that AWS is really good with this.

Their paid technical support (the 100-200$ one) is great and responsive, with an easy way to escalate if a response isn't helpful.

For what it's worth, I had similar experiences with GCP's paid support. Callback from a real human within 10 minutes kind of support.

So are most account managers, their paired SAs and escalations into product teams.

Hell I got a sit down with the engineers in Amazon Go (the walk out of the shops and pay automatically thing) because I was curious. As a consulting partner!

Reply on news.ycombinator.com