He mad, bro?
I think he mad.
A former Google engineer who worked on a library at the heart of "nearly every Java server at Google" has dubbed the company's much-ballyhooed backend software "well and truly obsolete". In a blog post published earlier this week, Dhanji R. Prasanna announced that he had resigned from the company, and though he praised Google …
I think he mad.
"As a member of the Google Wave team"
Not at all bitter, then
"Not at all bitter, then"
Of course you can be bitter when leaving an employer because you didn't get to make a difference, but that doesn't mean the guy doesn't have a point. Frequently, employers pooh-pooh criticisms about stuff like agility - Google is supposed to be about responding to trends - and end up telling guys like this to "stop rocking the boat", instead of taking the criticism on board and improving the way things are done.
From what I've heard about Google's infrastructure, none of this surprises me at all. (It's laughable when someone in this discussion tries to suggest that open source projects aren't as reliable as "The Google" when there have been some pretty intrusive outages at "The Google".) It would also explain why Google are always looking for "site reliability engineers".
God, what a whiner (whinger for you Brits?).
Imagine. Extremely large installations of software, currently in a state where behavior is very well known, and he moans about them not updating quickly enough or often enough to entirely new architectures and technologies?
Oh. Horror of horrors.
And coders get upset when we tell them managing them is like herding cats! Agreed, it does sound like he was most upset about the lack of pace when he didn't stop to consider that everything has to move in lockstep to avoid one new component stuffing the whole lot up. A large corporate system is often composed of many applications all working together, and the control issues of managing development grows exponentially with each added application. I worked with one system that had grown at one point to just over three-hundred individual projects, all of which had to be kept in lockstep to ensure it all worked seamlessly. Most of the project managers had ten-plus individual projects on the go, and most hadn't a clue about other projects they impacted on but which weren't in their immediate area. Everything from overall strategy to individual project and total solution testing had to be co-ordinated. Quite often, everything would go on hold whilst one small but crucial cog in the machine lagged on development. It was a monster, and the biggest cat herd I've ever seen, but I'm sure it wasn't as big as the Google system is.
map/reduce alone is a big idea.
"I've gotten prototypes off the ground, shown it to people, or deployed them with hardly any barriers."
Like testing perhaps?
It's not like Google going down a for a couple of days would be a problem!
Or backwards compatibility?
By his own admission, these were new apps, so whatever they did was, by definition, the correct behaviour. Writing such things is, how shall I put it?, "substantially easier" than writing an app where the specification is "whatever the previous version did, and you'll have to reverse engineer that because this thing just kinda grewed and there never was a formal spec".
I guess I'm slow, but getting an app out in a day, would that be "Hello World" plus a bit? As is later reported, he's a self-admitted hacker, he'd hardly fit into a huge corporation then would he?
Java is a security nightmare and that is what this idiot chooses as an example?
He must have suffered some horrific brain damage recently.
I think he means "Obselescent". If it was obsolete then you could not get the right sort of electricity to start it up, or something.
That said, he may have a point. Google got where they did today by re-inventing the wheel. If they stop doing that then they will become AltaVista or Yahoo. Continuous innovation, like Mao's continuous revolution, is needed to stay at the top.
I, for one, don't think he is mad, but he might be ill-informed. I suspect Google have the resources to re-invent their infrastructure and port silently to a new version, and I rather think they have done this already, at least once.
as "Obselescent". Obsolescent OTOH relates to obsolete and is what he meant. But back to the point, continuous innovation, yes, but more important is "if it ain't broke, don't fix it". If the basic infrastructure works, innovate on top of it until there's something about it that is no longer optimal, then change it.
To me, it all sounds a bit "look, new things, oooh shiney!".
Welcome to the real world. I'm sure people said Ford's model T production line was obsolete old technology just as soon as the world's second car production line came on stream.
At my place we have tons (imperial) of old stuff just as we have tonnes (metric) of slightly newer, but still just as obsolete, stuff. Google will have the same - it is the price of success. :-)
You can piss on the Goo all you want, but their platforms work. I prefer "sluggish and over-engineered" to "sylphlike and provisional".
I'd rather have my engineers confined to the vacuum cleaner amalgamating a homogenous mesh
than wandering about the room spinning exquisite incidental perturbations.
Prasanna will see the light once he has to oversee the support of an ethereal code base.
He probably feels the same way I did after leaving my first job...and until 2 weeks after starting my second.
So, his projects failed or wasn't allowed. Do you hear anyone from MS, IBM, Apple? These things must be happening there daily too.
For example, did any Apple engineer talk bad about Mach kernel publicly? I don't say there is a problem with it but some people almost partied when (false) rumour of it being abandoned and these people are very advanced, top of the league developers.
There is a way to do things and there is a complete rude way. I really wonder the NDA he signs if a big company hires him. I bet first article will be covering this.
Funny that the real obsolete (!) things people talk about are COBOL and Fortran and no matter what they say, the code continues to run since it works.
... of the fact that that the world just went through a test to see if we could finally turn off a protocol that was deprecated in 1998... ("world IPv6 day" yesterday)... the results? No. 31% of networks still fail to comply with PMTU discovery.
I would guess the Google using a 5+ year old MapReduce implementation is still close to cutting edge in the corporate world.
that tired "old = obsolete" thing again; Not that ten years is particularly old.
Agree with other posters: there is likely to be something more behind this apparent whining. Acareer-limiting move perhaps...
OS X Snow Leopard and upcoming Lion (and naturally iOS) still runs on very same principles of a 40 year old technology.
As they look super cool and trendy, people forget that fact.
If you're impressed by shiny OS bling with wibbly animations then I guess yeah. I include Win7 and Ubuntu's guff in that as well.
Some of us prefer simply and functional and not getting in the way of what we want to do.
Trotsky was all about constant revolution.. mao was just a wannabee!
Goofrastructure:About 347 results (0.18 seconds)
Maybe he's holding it wrong.
... who contributed to guice, critique any other piece of software and expect to be taken seriously?
Real-world, deployed code isn't bleeding edge.
Film at 11.
So what ? Is is rusting ? No. Does it work ? Yes.
If a 10-year-old program causes so much intellectual anguish to that guy, he'd better not learn that banks are using 50-year-old Cobol code that still works a charm.
Oh, and the technology behind the steering wheel is centuries old now, does that mean we should change to joystick ? No.
Please keep this guy out of any serious industrial project. Changing everything after 5 years just because the code "is getting old" is not something we want in our daily lives. The walls of my house are over 40 years old now, and I hope they'll stay just the same for much longer.
You have your 10year old program currently being supported by your IT guy...it works great and rarely fails. He then leaves, and you get Bob. Bob is a uni graduate with 2 years industry experience in the latest and greatest languages and techniques... unfortunately Bob doesn't have experience in the old languages and techniques, and panics...marking the system down as old and useless and in need of replacement...either the company agrees or finds someone else. They always find someone else due to perceived cost.
Now 10 years down the line Bobs replacement is doing well, the system is up and running and working perfectly with the same rarity of failures as with the original IT guy...But Bobs replacement retires, or leaves, or gets caught in an awkward position involving bread sticks and mango juice with the canteen lady by the CEO, and you need to employ someone new....
Who are you going to get that has the skill set to run the software? and at a price that means they wont be earning as much as the CEO? Most of the people leaving UNI are younger than your software, the ones that have the skills have had those skills for 25+years and are already much more successful with their private consultancy business than you will ever make them. Wouldn't you like to look back and fondly remember upgrading your software so that it can be supported by anyone for a low cost to the business rather than panicking when your company is running without the software they have become reliant on because one of those rare failures has happened and you're current IT guy would rather setup iPads for board members than learn how to support a system that is so old even the documentation has started to disintegrate?
It's called "documentation", and I don't mean a few comments in the code. If you have good design, implementation and operational documentation, plus well-commented code, you can take a green code monkey and get him to modify and update code written by the best dinosaur. Problem is, most people are like you - they don't know fudge about how to document anything. The other problem is good documentation was rare 25-odd years ago because few realised how essential it was. Most companies thought they'd only be running the same code for a few years, not thirty! Which is why we have so many companies running inhouse COBOL or C/C++ code from the '80s, and they are too scared to change because they don't actually know how it works.
and all you'll get is a face full of his faeces that he threw at you
while you wipe them off, you get to watch him masturbating.
and you'll deserve it, QA man ;-P
Literal in-flight redesign dramatised:
It works, doesn't it?
I hope, for his sake, that this bloke looks back and cringes.
If not, he ain't growed up much.
If one third of great ideas and great improvements get adopted you're doing damn well!
They could modernize their infrastructure by moving it to Azure.
Sounds like the guy just doesn't like working in such vast companies with hundreds of millions of users.
I recollect when google first arrived. Came from no where, but each such came back with solid precise answers. Today, searches on Google come back in millliseconds, and are the same precision.
Without being harsh about this, but its not broken, and at least in search seems not to need 'fixing'.
Other areas of the google empire may indeed bring or highlight weaknesses or lack of something, but not so much in their core business... search
I have 10 year old code on some of the websites I run. It still does the job it was written for very well and I see no reason to waste time and effort re-writing it because it is old. I re-write it when it ceases to be fit for purpose.
Google makes their money selling ads. As long as they're the front-runner in that market, it doesn't really matter whether their infrastructure is passable or top-notch. The marginal value of Google's infrastructure being better than Facebook's is questionable.
sounds like he did them a favour by resigning
Except when it works.
The meh is strong in this one.
Dhanji R. Prasanna, meet the Peter Principal.
Glad you figured that out, or did you?
Biting the hand that feeds IT © 1998–2017