Hacker News Reader

Comment by SwellJoe | Hacker News Reader

Do you really think the team that made, say, Google Talk, were the ones who wanted to kill it and push everyone to a different product? I don't know who made either one, but I would be shocked if the decision maker that pulled the plug had anything to do with the creation of the product. I, personally, don't like to kill my babies.

Clawing back bonuses for something out of the control of the engineers seems like a dystopian nightmare, and any company that tried it would, hopefully, die a fiery death after an exodus of talent to more reasonable employers.

View on HN

Do you really think the team that made, say, Google Talk, were the ones who wanted to kill it and push everyone to a different product?

Man, for all the lore and blogging that operates around working at Google, the skills of people who get hired, plus the first-hand accounts of what it takes to move up the ladder there, I'd think they'd be able to release things by people who make their products less killable. Ah, but reality rarely meets the legend.

This is my point: what if what gets released by Google is just bad software engineering? Maybe SOLID-deficient. If products are killed because they don't have the features contained in subsequent iterations of the concepts, how come the products were not extensible, or capable of being grafted onto something else? I seem to remember reading about this kind of thing being a big part of software engineering.

I think the acronym Google always misses out on is KISS (Keep it Simple Stupid) because no one there is "stupid." If you only hire geniuses, no one wants to write documentation or do things the boring/easy way that would create more maintainable software.

Instead everyone there has to use the latest framework or best practices, then re-engineer things to prove they deserve their top-performer salary.

I think the first Google Hangouts was written in Angular 1? Code rot from frameworks like that will ensure the product will die in 5 years at a company like Google. Everyone at Google is a "top-performer" so they want to use the latest development tools and shiny things and no one wants to upgrade/maintain 5 year old code written in an old framework.

I think a lot of other companies get around this by hiring less than top performers. Those types of coders will maintain legacy systems because they don't have as much pride. So I think it's mainly a problem that Google has a culture of tech elitism, instead of a culture that focuses on user satisfaction.

I think you are correct but I want to add that most of the top programmers I have met have had zero issues with doing maintainance work. Just look at many of the big names in open source if you need some examples.

I think Google's culture is to blame, but this culture is ptobably created much due to only hiring top performers, rather than other companies who have to do with a mix of skill levels.

Every large old piece of code is "bad engineering" to the next generation that looks at it. That doesn't mean throwing it away and throwing away all the users and starting over is a rational path forward. The new engineers will just fuck it up in new and exciting ways and won't have all of the experience of the old version built in (and will have to learn those lessons over again, probably).

If you're Google, you already have APIs that serve client applications (there's no such thing as a monolithic Google app, because Google can't launch anything at small enough scale to do a monolith). If your engineers really fucked up the first one so bad you can't fix it and improve it (which I don't believe to be the case, nothing that bad would survive production at Google scale, particularly for a popular product like Hangouts), you just rewrite the damned clients, call it the new (version 2, whatever) Hangouts, and don't confuse your customers (yet again) with a maelstrom of wacky new chat-like products and force them to choose to install and learn something new (again).

But, it seems like a real stretch to say that Google secretly has a bunch of unskilled hacks working there, despite all the evidence to the contrary. And, it's even weirder to suggest that if Google is secretly a den of incompetence that starting over from scratch would be a good idea.

My point is two-pronged: Starting over with a new confusingly named/positioned product is bad business. Throwing away the old, functional, product, to launch a new one that is very similar (how different can a chat really be and still be useful and recognizable?) is bad engineering.

Every large old piece of code is "bad engineering" to the next generation that looks at it.

I'm pretty sure this is only true to undergrads in the dorms (and people who still think like them). Computer Science has its own form of Medical Students Disease[1]. NIH Syndrome[2] is also more prevalent than it might appear.

it seems like a real stretch to say that Google secretly has a bunch of unskilled hacks working there

it's even weirder to suggest that if Google is secretly a den of incompetence

Nobody said these things, but to address the hypotheticals, a) there is a difference between unskilled and ignorant ("prone to ignore the existence of useful concepts," let's say); b) are there any other forms of competence that might address the ability to launch something impressive that does not fly? Couldn't they be partly incompetent? After all, pobody's nerfect.

We talk about Louis Bleriot much more than Percy Pilcher, and to continue the analogy I'd say Google has gotten very very good at making Gee Bees[3].

1. https://en.wikipedia.org/wiki/Medical_students%27_disease

2. https://en.wikipedia.org/wiki/Not_invented_here

3. https://en.wikipedia.org/wiki/Gee_Bee_Model_R

> I, personally, don't like to kill my babies.

I do. Software isn't my progeny or legacy. It is the tools in my workshop. If I can use one tool to do the work of five, I'll gladly downsize to declutter and simply my life.

Finding self-worth in the longevity of tools is an emotional anti-pattern.

I think you're taking him a bit too literally. In these examples, you're not looking at simplifying anything. You're not getting rid of unneeded code. You're getting rid of debugged and stable code in favor of writing something new from scratch because fuck all knows why.

In this case, worst case, it's multiple groups of engineers all advocating for their pet projects. They can all be wrong and concerned about personal sunk costs instead of having some perspective and humility and working together to the extent it makes sense.

I gather maybe the Google advancement structure discourages doing nothing and generally being stable when it makes sense, in which case there could be plenty of improvement to be had all around.

Oddly enough, I assume the Google advancement structure values anything but stability. You launch products to get promoted. Maintaining them is for fools and losers.

Granted, I have no inside information. That just fits the externally observable information and the tiny amount of corporate politics that occasionally makes its way public.

So, what part of Google's chat strategy fits your description of "downsize to declutter and simplify"?

Google has had something like...seven(?) chat and chat-like projects, and each new iteration of "let's kill the most popular chat product we have" seems to result in several new chat-like things, most of which fail and many of which are weirdly complicated and/or confusingly branded/messaged.

I was agreeing with your point. It seems pretty obvious that the end goal is something simpler for both the engineer and the end user. The defensiveness of some engineers to protect their particular contributions is a net negative.

It seems pretty obvious that the end goal is something simpler for both the engineer and the end user.

I don't mean to be short, but...based on what evidence?

Reply on news.ycombinator.com