Facebook and Twitter started out small and grew. That's also true of Google, Amazon, and just about any other very high volume site. This is different because they had to build a site and then, on the first day, turn on the fire hydrant all the way. I'm sure there are plenty of things they did wrong, and it was probably very badly organized. Nevertheless I'm curious what the best way to handle something like this would be. How many people have worked on a project where they had to go from zero to millions of users one day? Obviously massive test capability would be part of doing it right, but often that doesn't wring out all the unforeseen cases.
Exactly. This a conference, not a meeting. Big difference. A productive meeting should last no more than an hour, and involve less than a dozen people. A conference involves hundreds of people over several days.
I attend virtual meetings all the time, and don't find them any less productive than face-to-face. I do find, for reasons I've never quite figured out, that having met my colleagues face-to-face at some point makes collaboration go much more smoothly. But it only has to happen once or twice, maybe repeated once or twice a year. That's the sort of thing that happens at a conference. The rest of the time colleagues and collaborators can send email and have phone calls (desk top sharing can be helpful, but video I find useless).
You mean like the Google self driving car which has done some 500000km without accident?
Google press releases tell you very little about the actual test conditions. Were these cherry picked routes that had been carefully mapped? Heavy traffic, inclement weather (not sure they know about that in SV), etc. How many times did the driver decide "oops, better switch to manual control because I know these things don't work well under these conditions".
You just need to pick an architecture and code in a bug free way.
Why haven't other people thought of that? The secret to quality software is to leave out the bugs.
Google have the expertise to design their own hardware
There is a small difference between servers/data centers and cars. Maybe Google should start designing airliners too?
shown some ludicrously good uptime in their data centres
Data center reliability, especially of the sort that Google worries about, consists mostly of massive redundancy. Safety critical systems have redundancy, but not 1000x redundancy.
Because engineers suck at software... Hardware engineers specifically.
What types of engineers were you considering, other than software and hardware?
BTW, I've had more trouble on hardware/software projects with software people who understand nothing about the hardware they're writing code for, and have to be hand-held every step of the way. Unlike you however, I won't generalize. I've seen other software people who are very good at interfacing with custom hardware, including RF, optical systems, etc. They have a level of understanding beyond pure software, and are always willing to learn more.
they all SUCK horribly at it
Take your nose out of the clouds. Some of them suck at it, and some are quite good.
I have been cleaning up engineer code for decades.
And you're living in the past. What you say was far more true in the 80's especially the early 80's, and also the late 70's. Hint: it's now the 21st century.
Morons.
Of course, only software engineers as good as you are not morons. BTW, how's your RF ASIC design coming along?
Who would you trust to program a computer in charge of your life? A company who revolutionised the way we communicate and interact with technology? A company which offers incredible services which make our lives better thanks to gobbling up talented software engineers.
Or.
A company who's greatest innovation in the past 5 years...
The car company (most of which didn't ask for handouts, for example, Ford or Toyota). Google, for all their cleverness, has never produced anything that's safety critical. I seriously doubt their culture is suited to it. It's very different from "let's play with this cool new idea". That's why progress in cars and airliners is slower than with non-safety critical software. If the car companies need help with the software, they're better off hiring people, or companies, from aerospace. Ever look at writing code to DO-178B Level A? That's what you need for fly-by-wire systems, where a bug can kill you. It's also very tedious and boring work.
No, integrating embedded software with hardware is a whole different animal than writing "pure" software. Not that I have anything against open source for that, and some nice frameworks and so forth have been produced for it. But, making a few casual hacks on something that's safety critical is not a good idea.
Not me. Google is well known for its cool ideas, but not for producing real-world consumer goods with serious safety requirements. It's a whole different animal. There's plenty to criticize car companies for, but they do produce products where the failure of certain parts (brakes, steering) can kill you, but they rarely do. Contrast that Google's perpetual beta approach. Brakes failed? You should have upgraded to version 1.2.3.4bx build 427. Google is not and engineering company.
Car companies are working towards self-driving cars, by taking a bottom up approach. For example, self parking and keeping a car in the lane. Moreover they actually put this stuff in the hands of customers, by the millions. You learn a lot by doing that, and is a lot more useful than having a handful of wonder cars. For first prize in the science fair, Google wins hands down. For real world engineering, any car company beats it.
It reminds me of the history of AI. After a few decades of jerking around, people finally realized that it's too difficult to solve with a top down approach. Instead, real world progress was made with a bottom up approach. That's Google vs. the car companies in a nutshell.
The Mines Java Toolkit (JTK) is a set of Java packages and native (non-Java) code libraries for science and engineering.
In other words, there is C/C++ wrapped in Java. That may be a good idea for many applications, but it's not a measure of Java's speed.
Ye olde Computer Language Benchmarks Game has pure Java vs. pure C++. There is one test where Java is slightly faster than C++ (and even that advantage disappears depending on which of the four processors they tried). Otherwise C++ is up to 3x faster, and an average, from glancing at the graphs, of about 2x faster.
I tend to trust these benchmarks because anyone is free to defend their favorite programming language by submitting a faster program. Hence you don't get the bias that's all too common in benchmarks, where someone tries to write Java in C++, or vice versa. Those benchmarks are also running pretty up-to-date versions of g++ and the Java HotSpot Server VM, so you don't have "five years ago A was X tines faster than B, but it's changed".
I'm sorry to hear that the acquisition caused you to lose your job in the Sun marketing department. Based on the fantastic job you guys did though, you ought to able to find something else.
Slashdot Mirror
Facebook and Twitter started out small and grew. That's also true of Google, Amazon, and just about any other very high volume site. This is different because they had to build a site and then, on the first day, turn on the fire hydrant all the way. I'm sure there are plenty of things they did wrong, and it was probably very badly organized. Nevertheless I'm curious what the best way to handle something like this would be. How many people have worked on a project where they had to go from zero to millions of users one day? Obviously massive test capability would be part of doing it right, but often that doesn't wring out all the unforeseen cases.
Exactly. This a conference, not a meeting. Big difference. A productive meeting should last no more than an hour, and involve less than a dozen people. A conference involves hundreds of people over several days.
I attend virtual meetings all the time, and don't find them any less productive than face-to-face. I do find, for reasons I've never quite figured out, that having met my colleagues face-to-face at some point makes collaboration go much more smoothly. But it only has to happen once or twice, maybe repeated once or twice a year. That's the sort of thing that happens at a conference. The rest of the time colleagues and collaborators can send email and have phone calls (desk top sharing can be helpful, but video I find useless).
Most people who are outraged by this would rather have some government movement that forces BN and Amazon to carry what they don't want.
How do you jump to that ridiculous conclusion? Please clarify what stereotypes and other assumptions you're using.
After all, it's the first amendment, right?
No, and judging from the comments here, it seems most posters understand that.
Wrong. The UK, where this happened, doesn't have a First Amendment.
Even in the US it wouldn't be a 1st Amendment issue, since the government has nothing to do with this.
Double whammy - it's also full of socialist propaganda.
Britain's weird. ... We're bastions of hypocrisy, we are.
Sorry, but you've got nothing on us Yanks there.
You forgot the Bible. There's some pretty racy stuff in there, and a lot of obviously socialistic stuff.
Is there a name for a joke that's so bad, it's good?
A pessimist is what an optimist calls a realist.
It's either implemented by off-shore developers who have never seen a car
You've just convinced me never to get into a car that was made after 1990.
In fact I agree with you. I just conceded the OP's point to concentrate on other points. More rhetorical a rhetorical trick than anything else.
You mean like the Google self driving car which has done some 500000km without accident?
Google press releases tell you very little about the actual test conditions. Were these cherry picked routes that had been carefully mapped? Heavy traffic, inclement weather (not sure they know about that in SV), etc. How many times did the driver decide "oops, better switch to manual control because I know these things don't work well under these conditions".
You just need to pick an architecture and code in a bug free way.
Why haven't other people thought of that? The secret to quality software is to leave out the bugs.
Google have the expertise to design their own hardware
There is a small difference between servers/data centers and cars. Maybe Google should start designing airliners too?
shown some ludicrously good uptime in their data centres
Data center reliability, especially of the sort that Google worries about, consists mostly of massive redundancy. Safety critical systems have redundancy, but not 1000x redundancy.
Very good point. A self-driving car can be a land bound missile.
Because engineers suck at software ... Hardware engineers specifically.
What types of engineers were you considering, other than software and hardware?
BTW, I've had more trouble on hardware/software projects with software people who understand nothing about the hardware they're writing code for, and have to be hand-held every step of the way. Unlike you however, I won't generalize. I've seen other software people who are very good at interfacing with custom hardware, including RF, optical systems, etc. They have a level of understanding beyond pure software, and are always willing to learn more.
they all SUCK horribly at it
Take your nose out of the clouds. Some of them suck at it, and some are quite good.
I have been cleaning up engineer code for decades.
And you're living in the past. What you say was far more true in the 80's especially the early 80's, and also the late 70's. Hint: it's now the 21st century.
Morons.
Of course, only software engineers as good as you are not morons. BTW, how's your RF ASIC design coming along?
Automotive software is mostly pretty boring.
Mostly true, though you also have to remember that in embedded systems the software is just another component, not the end product.
Consequently, for developers in the field there's rarely a significant challenge.
For safety critical systems, nothing could be further from the truth.
Sometimes it feels like inability is hidden behind quality
WTF? If you're system is of high quality, it means you're incapable?
which is often mostly paper or comprises gaming some statistics
Or not having cars crash every time a customer encounters a bug.
I doubt the automotive industry itself could pull anything like this off on their own, even if they wanted to.
And how much experience does Google have with hi-rel software? Hint: zero.
Who would you trust to program a computer in charge of your life? A company who revolutionised the way we communicate and interact with technology? A company which offers incredible services which make our lives better thanks to gobbling up talented software engineers.
Or.
A company who's greatest innovation in the past 5 years ...
The car company (most of which didn't ask for handouts, for example, Ford or Toyota). Google, for all their cleverness, has never produced anything that's safety critical. I seriously doubt their culture is suited to it. It's very different from "let's play with this cool new idea". That's why progress in cars and airliners is slower than with non-safety critical software. If the car companies need help with the software, they're better off hiring people, or companies, from aerospace. Ever look at writing code to DO-178B Level A? That's what you need for fly-by-wire systems, where a bug can kill you. It's also very tedious and boring work.
No, integrating embedded software with hardware is a whole different animal than writing "pure" software. Not that I have anything against open source for that, and some nice frameworks and so forth have been produced for it. But, making a few casual hacks on something that's safety critical is not a good idea.
Not me. Google is well known for its cool ideas, but not for producing real-world consumer goods with serious safety requirements. It's a whole different animal. There's plenty to criticize car companies for, but they do produce products where the failure of certain parts (brakes, steering) can kill you, but they rarely do. Contrast that Google's perpetual beta approach. Brakes failed? You should have upgraded to version 1.2.3.4bx build 427. Google is not and engineering company.
Car companies are working towards self-driving cars, by taking a bottom up approach. For example, self parking and keeping a car in the lane. Moreover they actually put this stuff in the hands of customers, by the millions. You learn a lot by doing that, and is a lot more useful than having a handful of wonder cars. For first prize in the science fair, Google wins hands down. For real world engineering, any car company beats it.
It reminds me of the history of AI. After a few decades of jerking around, people finally realized that it's too difficult to solve with a top down approach. Instead, real world progress was made with a bottom up approach. That's Google vs. the car companies in a nutshell.
This is what companies do when they have too much cash. How much is this building per square foot?
I'll take the one in Rome - much better artwork.
The Pentagon ... is a building.
You said it first. That's the first thing that came to mind when I saw it. This is the great innovation they came up with after 70 years.
Ok, so where are some better benchmarks? Everybody knows benchmarks have problems, but without them all you've got is hot air.
From your link:
The Mines Java Toolkit (JTK) is a set of Java packages and native (non-Java) code libraries for science and engineering.
In other words, there is C/C++ wrapped in Java. That may be a good idea for many applications, but it's not a measure of Java's speed.
Ye olde Computer Language Benchmarks Game has pure Java vs. pure C++. There is one test where Java is slightly faster than C++ (and even that advantage disappears depending on which of the four processors they tried). Otherwise C++ is up to 3x faster, and an average, from glancing at the graphs, of about 2x faster.
I tend to trust these benchmarks because anyone is free to defend their favorite programming language by submitting a faster program. Hence you don't get the bias that's all too common in benchmarks, where someone tries to write Java in C++, or vice versa. Those benchmarks are also running pretty up-to-date versions of g++ and the Java HotSpot Server VM, so you don't have "five years ago A was X tines faster than B, but it's changed".
Benchmarks are the worst possible way of measuring program speed, except for all the others that have been tried from time to time.
-- with apologies to W. Churchill
I'm sorry to hear that the acquisition caused you to lose your job in the Sun marketing department. Based on the fantastic job you guys did though, you ought to able to find something else.