Google App Engine Support

Why Google's $500 a month Enterprise Support for App Engine mysteriously takes a 6 hour break from 6pm to midnight (PST) might be explained by looking at a world timezone map compared to a map of Google offices around the world.

Do Google's office locations have any relation to the concentration of App Engine users? If so, this may be the least disruptive period since most of the 6 business hours affected are over the Pacific. Are there many (any?) App Engine users in Japan, New Zealand, Australia or surrounding areas?

On the other hand, it could be to provide an exclusive window for third-party support from companies like Cloud Sherpas.

But then again, maybe running an around-the-clock technical support help-desk operation is just not what Google does best.

Google is, after all, an innovator.

Google creates leading-edge software systems. Their culture is one where everyone is thought of as a superstar... or an aspiring one. Google hires and promotes self-motivated, creative, impatient, out-of-the-box personalities.

While the best help desk people are compassionate, patient, methodical, thorough personalities that enjoy the satisfaction and confidence that comes from knowing the answers (Most of the the time. If they could just get the caller to ask the right question.)

It would make sense to outsource the help desk... but the logistics can never work.

How can a third-party keep its staff up-to-date with almost daily changes?

We are rapidly coming to expect software problems, particularly online software problems, to be fixed in a matter of days (or hours). Though many fixes to application software are internal and require no help desk procedure changes, most fixes in APIs like those for App Engine will at least alter the "best" way to do things if not the "only" way.

No, the only way Google can best its rivals for support is to automate it.

Google is just going to have to do what programming language designers have been trying to do since Grace Hopper developed COBOL... They're going to have to create a truly self-documenting language.

Be it Go, Dart, or something to come that barely resembles a "language", Google needs a system that communicates how to use it automatically from the code itself.

We already have IDEs that provide syntax and other documentation to the programmer. Maybe there could be deeper levels (in a wiki?) that are automatically generated from the code itself and accessible from outside the IDE. These would then be enhanced with feedback from developers, help desk personnel and users.

I expect such self-documenting systems exist... somewhere.

If anyone can bring them to world... Google can!

Resources

• Google to App Engine customers: Don't call us, we'll call you
  InfoWorld, October 13, 2011, Bill Snyder
  
• Turning Information into Knowledge:
  Information Finding as a Collaborative Activity
  Kate Ehrlich and Debra Cash

"Earth to developers: Grow up!"

September 01, 2011 by Neil McAllister | InfoWorld

A Comment...

Each language has its own strengths.

Forth taught me bottom-up programming. Pascal taught me structured programming. C taught me linked-lists and pointers. SQL taught me declarative and top-down programming. C++ and Javascript taught me object-oriented/based programming. I've learned countless other indispensable techniques working in dozens of other languages (often not by choice I might add).

If you're a programmer -- that is, if you cannot go very long without feeling compelled to program something -- then learning a new language is like a cabinet-maker getting a new tool or a composer hearing an exciting progression he's never heard before. You immediately start cogitating the possibilities: problems you can solve more elegantly, features that now become practical to implement.

Every programmer brings to a project a different set of experiences and skills. The most successful projects are the ones that take advantage of those strengths.

To be sure, choice of tools is still largely dictated by organizational concerns like licensing, maintainability and compatibility with existing systems. But programming has reached a level of maturity where there are usually a number of different tools that can be used to accomplish the same goals. Thus, there are fewer valid arguments to use a given tool exclusively.

Perhaps it then could be said that...

Good programmers are experts in using their tools.

Great programmers are experts in choosing their tools.

Let's all grow up and accurately access our own abilities, then work to mesh those abilities with others to produce the best software we can.

Is .NET Today's UCSD Pascal?

Discussion with a colleague reminded me of some work I did related to ASP.NET and ADO.NET a few years ago. The CLI concept is a logical next step for Microsoft. They just need to remember what happened to the last player that tried that...

In the 1980s, UCSD Pascal was gaining in popularity. Versions were coming out for a lot of the microcomputers of the day and people doing serious programming liked it because it was a "structured" language, unlike BASIC's wide-open approach that often resulted in unmaintainable "spaghetti code".

Instead of being interpreted as most of the BASICs were or compiling to machine code like COBOL or C, UCSD Pascal compiled to an intermediate pseudo code ("p-code") that was then interpreted at run time. So it was faster than BASIC but slower than compiled languages like C.

With the success of UCSD Pascal, they started adding languages that would compile down to the same p-code so you could write in whatever language you liked and the end user only needed one interpreter to run it. Great!

Then a little company named Borland came along.

Borland came out with Turbo Pascal which had the first Integrated Development Environment for microcomputers. In that less than 40KB IDE, your program could be compiled and linked in seconds instead of taking several minutes in UCSD Pascal and other compiled languages. It also provided keyword help (very attractive to self-taught programmers) and was very inexpensive (also attractive to starving self-taught programmers). Not only was the development process much faster, but because it compiled to machine code, the resulting programs ran much faster than the p-code interpreted ones.

Turbo Pascal's success took the language makers in a new direction and pretty much spelled the end of p-code languages.

Microsoft's CLI is a p-code system. Different name. Different innards. Same idea. It addresses a problem of large organizations employing many programmers with different backgrounds.

But is it practical for the plethora of portable devices poised to dominate software development?

It may work fine for the new "big iron" ("big aluminum?") environments of large websites though.

At least until a more nimble competitor comes along.