Since Google released the Dart spec today, I wanted to share my speculation on the reason Dart exists: Dart is a new technology to solve a cross-organization engineer people problem, internal to Google.
I have no inside knowledge, but reading between the lines, Google had several sets of engineering efficiency problems.
This is not surprising. Google is a massive, incredible engineering organization. They are creating cutting edge solutions to some of the world’s hardest problems. I would expect them to have huge people challenges;
sudo herd cats still doesn’t work.
Classic engineering problems
- Code reuse
- Cost of shipping a project, etc.
- Standards (Code Quality, Security, etc)
A classic mistake is to solve these things with technology first, before solving the actual people-oriented problems. Technology can help enforce standards and make code reuse easier, but tech alone will fail.
As I day dream, I tried to imagine problems that could result in Dart as a (flawed) solution…
Perhaps Google spun up 6 teams to investigate and solve 6 problems (Why isn’t project X using GWT?, Why did project Y fail? Why did project Z take 6 extra months and 30% more $$$ to ship?).
Being an awesome company, these postmortems may have bubbled up into a more core question: How can we solve this once and for all?
One of many possible analysis:
An example of flawed logic that could lead to project Dart:
- We couldn’t get everyone on board with GWT, so
- We employee some key language pioneers in enterprise languages, so
- Google needs a ‘programming in the large’ friendly platform like Java was for the last decade.
The end goal is enticing
- Lower power usage and data center costs, be greener
- Ramp up new engineers quickly
- All projects reusing standard language and APIs
- Lower cost of engineers switching teams
- Avoid legally tainted platforms (Java)
- Provide puppies and rainbows for all
Some of these are real issues. Some of these are nice to haves. Just technology isn’t the right solution to all of these problems.
Some, definitely not all, but some people at Google have this perspective:
Google hires all the smartest people of the world. We will figure out how to solve the world’s problems; you will live in our resulting products. You’re welcome.
Sometimes being the smartest person can blind oneself to the actual root problem. Having an engineering bent causes one to look at fixing tools instead of process.
In 5 years, various hypothetical teams across my imaginary Google will have drifted back into a Dart-based Babylon, if hypothetical Google doesn’t fix the core communication and standardization issues which may have prompted Dart’s creation.
These are not fun decisions to make or communicate, but that is the point of project and engineering management.
Creating Dart is expensive (language, tools, runtime, etc), but may give them the social framework to communicate people oriented engineering changes (employees will all use Dart) that address the real core issues. So ultimately Dart might not be a loss for Google internally.
Dart alone will do nothing to solve the root problems that prompted Dart.
Again, this post is based on a hypothetical situation internal to Google. I’ve pieced together this day dream from my own “Enterprise” experiences, various Google posts over the years, etc to resolve why Google would create the Dart platform.
I hope I haven’t offended any of my friends at Google and my speculation is probably wildly inaccurate. If nothing else this post is a parable to talk about solving people problems directly before building tools.
But the real world announcement has some real world impact…
Collateral Damage from the Dart Launch
An unintended consequence of the Dart launch is that it may weaken Google’s efficiency in promoting web standards. It is a very confusing story to explain how promoting the Dart platform and working towards next generation, open web standards are not conflicting Google projects.
Example Dart versus CoffeeScript:
Early adopters in the webdev community don’t see Dart as more attractive than CoffeeScript which they see as having a superior syntax to Dart. Since both must compile down to JS, they are equally viable for experimenting with language semantics. So on first blush, Dart is a meh to CoffeeScript commentators on Hacker News and Reddit.
I’m probably wrong, as I don’t have much insight into Google’s engineering organizations, but it is quite possible that Dart is a facile throw at the wrong target.