Ex-Google engineer dubs Goofrastructure 'truly obsolete' 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 …
"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.
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 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. :-)
This post has been deleted by its author
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.
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.
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
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
