Mike Coyle’s Weblog

Google App Engine was announced last night. This is a service that allows you to write a web application in Python and deploy it to Google, where it can run atop Google’s uber-scalable infrastructure. Here is the transcript and video of the announcement, where Kevin Gibbs from Google explains the App Engine’s value proposition (Easy to use, Easy to scale, and Free to get started.)

Like most big announcements, it’s the most sensational aspects of the story that emerge first. But I think that the broader impact of Google App Engine is a fundamental rethinking of the relational database value proposition among the RDBMS’ staunchest allies. Google makes a compelling case for deployment, so long as your application can live within its constraints.

I see data management as the biggest impedence mismatch between the Google App Engine and the traditional web application design. However, over time I’m certain that a set of patterns will emerge to aid the masses in bridging the gap between the relational model and the Datastore API.

They have some great stuff in the Datastore API, and Christian and I are already at work putting together some offerings to help companies attracted to Google’s Infrastructure-as-a-Service model objectively evaluate and/or embrace the App Engine for their web application needs. Email me if you’d like to discuss.

So that being said, I’ll argue the following:

• Is it a giant piece of flypaper to help Google acquire the next generation of startups? Maybe, but I contend that the real killer next-generation apps will need more feature-rich networking capabilities. Let’s wait until we see what kind of XMPP/GoogleTalk integration comes along.
• Is it a sign that commodity web hosting providers are going the way of the corner video store? Perhaps.
• Is it a welcome counterbalance to the Ruby-on-Rails hype machine in the dynamic language arena? Yep.
• Is it a final blow in the in the Google vs. [INSERT NAME HERE] battle for the hearts, minds, and wallets of the IT crowd? No, the Infrastructure-as-a-Service game is just beginning. The Amazon infrastructure offerings are generalized and piecemeal (by design), whereas the Google App Engine is more of a “vertical” play tailored to traditional data-backed web applications.
• Is it a symbolic victory of Django over Pylons in the Python web frameworks world? No, it’s a victory for WSGI. Django just happens to be up on stage, ably and graciously accepting the award on WSGI’s behalf. I think that the stuff coming out of the App Engine ecosystem in the coming weeks will provide additional validation to the idea that WSGI is Python’s not-so-secret weapon.

Lastly, I’ll throw out some predictions, none of which are Earth-shattering:

• An Open Source application stack that emulates the Google App Engine SDK’s runtime environment will emerge from the community for folks that want to build applications that are compatible with the App Engine, but do not want to deploy their application to Google’s cloud at the current time. Also, this stack would provide an option for companies that deploy a custom app to the App Engine, but subsequently wish to take their application in-house.
• Within time, you’ll see integration with other elements of the Google infrastructure (Docs, GTalk, Search, etc.).
• The next language to be supported will be JavaScript, but that will not come for quite some time.

A couple of months back, I had the pleasure of being interviewed by Susan Ladika for PM Network magazine (a publication of the Project Management Institute). They were doing an article about managing small project teams for the March 2008 issue.

I put together a bunch of content in advance of the interview. Now that the magazine’s hit the streets, I figured that I’ll publish the stuff that I wrote that didn’t make it into the article.

I did my prep work by writing out a fake interview with myself. I’m certain that I’ll recycle some of this content in future writings and talks, but here it is in its original form for your reading enjoyment:

–[BEGIN FAKE INTERVIEW]—————————————–

1) Your company uses the slogan “We help small teams solve large problems.” Please explain.

The needs of small, disciplined project teams are largely unrecognized and under-served in the project management community. We started our company to bring the necessary people, process, and technology to small teams so that they can leverage their constraints and deliver value to their customers in a predictable and instrumented fashion.

Too many small project teams either wander their way through the project lifecycle alone, or end up suffocating under a heavy, inappropriate layer of bureaucratic oversight that makes project delivery slower and more painful, but doesn’t necessarily reduce any tangible delivery risks.

We know that there’s a better way, so we put our money where our mouth is. ProjectPipe.com is our project management software solution that embodies our approach to disciplined, high-performance small team project management. Our target customers in corporate settings are the small boats of ambition floating in the sea of big company mediocrity. While we’re not here today to discuss ProjectPipe, any interested readers can find out more at ProjectPipe.com.

We are convinced that the future of project delivery is small, distributed teams. We are fortunate to be in a position to expedite this trend through our software, consulting, and writing.

2) But isn’t bigger generally better?

No. Having more people on your team is not like having more money in the bank.

For example, jazz quartets don’t want to be orchestras when they grow up. The two are different beasts.

If you try to run a jazz quartet like a symphony, you get bad jazz. Run a 20-piece orchestra like a jam session, and you end up with chaos. The same goes for project teams. If you run a small project like a miniature large project, you end up with….pretty much what you see in corporate environments everyday. Namely, too many meetings, lots of low-value boilerplate documentation, and other adminstrative overhead that gets in the way of solving the real problems at hand.

Don’t get me wrong, a team of 4 people still needs to play by the book, but it’s a different book.

3) Why does the size of a team matter? Aren’t there universal best practices for project management?

At a high-level, there are a number of universal truths that the Project Management Institute, and other organizations have done a wonderful job categorizing and articulating. However, when it comes time to tactically implement these best practices, you see the entire spectrum of implementation choices, from hyper-bureaucratic process overkill to Wild West-style chaos.

In theory, practice and theory are the same. In practice, they are profoundly different.

This is why it is so important to have strict adherence to a lightweight process. As a project manager, you want to spend your overhead capital wisely, applying documentation and other process-related protocols to the specific areas of project risk that are relevant to your project.

4) What types of things are more difficult for small teams, aside from the shortage of manpower?

There are three general challenges for a small team. First of all, distractions and overhead can be a significant drain of time and attention. Second, context switching can be expensive, as members of small teams often wear multiple hats. Lastly, having fewer team members to draw insight from can result in less diverse domain expertise brought to the table.

5) Are there any advantages that come from having a small team?

Certainly. Small effective teams understand the nimble clarity that comes with having few moving parts. They have conversations rather than meetings.

Small teams separate the wheat from the chaff, since there’s nowhere for underperformers to hide. As a result, I’ve found that higher-skilled resources are more likely to prefer working in smaller teams, since there’s a bit of self-selection at play. For example, rock stars know that poor performers are more interested in being the 16th person on a 16-person team than the 3rd person on a 3-person team.

6) What kinds of special needs do small teams have?

Small teams need to behave like small teams, not miniature versions of large teams, because bureaucracy doesn’t scale down particularly well. Small teams need to be led by a project manager that understands the dynamics of small team delivery. Specifically, someone who picks their battles carefully and doesn’t mind getting their hands dirty from time-to-time. Additionally, small teams need to use the best tools available, as they cannot afford to arbitrarily throw labor at problems.

7) Are there particular issues that come when team members are dispersed around the globe?

Small teams should strive for “location transparency”, regardless of the team’s physical locale. Collaborative technology (and the day-to-day practices that support collaborative processes) should be employed whether team members are separated by a hallway or an ocean.

8) What ways can small teams work most effectively to accomplish big tasks?

There are four aspects that drive small-team effectiveness: Planning, Process, Automation, and Asset Management.

• Planning: Small teams need to focus their efforts on understanding how the key moving parts of their project fit together so that they can proactively categorize and manage delivery risk. This is far more important than trying to optimize the workload balancing in your project plan, since you’re not trying to distribute lots of work among interchangeable resources on a large team.
• Process: Small teams should maintain strict adherence to a lightweight process. Individual heroics are not scalable nor predictable over time. Even small teams need to play by the book, but they need to make sure that it’s the right book for them.
• Automation: Small teams need to maximize the amount of work that they don’t do, and focus their efforts on the important stuff. If work cannot be avoided, it should be automated. Computers are really good at doing predictable stuff really fast.
• Asset Management: Small teams should manage their important data using some sort of version control mechanism. A good version control system acts as a time machine in case users need to review and/or compare previous versions of a document or other artifact, and a bank vault to protect a single, current version of the truth for each project asset.

9) I also found the comment intriguing that large teams are usually bands of small teams in disguise, and I’d like your thoughts on that.

We coined that phrase to help decision makers understand the true nature and composition of their organizations, and soften any negative connotations that the “small teams” concept would have in larger organizations.

At the end of the day, projects get talked about by large teams and completed by small teams (or groups of small teams working together).

Any team can make a decision. Only small teams make great decisions.

Any team can do work. Only small teams do efficient work.

It’s true that there is strength in numbers, but sometimes that strength lies in small numbers.

–[END FAKE INTERVIEW]——————————————

IBM invests in PostgreSQL vendor EnterpriseDB.

This is good news for two reasons: First, it throws yet another (big) blue chip name behind the PostgreSQL brand and ecosystem. IBM was one of 4 firms participating in EnterpriseDB’s C round of venture financing, which raised $10 million for the firm.

Second, EnterpriseDB is also rebranding their value-add packagings of PostgreSQL as Postgres Plus and Postgres Plus Advanced Server. The products used to be branded as EnterpriseDB Server and EnterpriseDB Advanced Server respectively. This new naming scheme should bring more brand recognition to the underlying PostgreSQL project.

For those not familiar with EnterpriseDB, their main claim to fame is an Oracle compatibility layer that they’ve built atop PostgreSQL. This allows firms to save a few bucks by replacing Oracle databases with EnterpriseDB’s distribution of PostgreSQL. They also provide support and other value-added software and services for customers using PostgreSQL.

Speaking of databases, I highly recommend checking out FLOSS Weekly: Episode 26 where the guest is D. Richard Hipp, the creator of SQLite. SQLite is the most widely distributed relational database in the world. Aside from the interesting technical content, the interview can stand on the merits as a human interest story of how one man’s pet project can have a huge impact on the world.

TurboGears is now at 1.0 release, and now has a new leader, Alberto Valverde. Best of luck to Alberto, and kudos to Kevin Dangoor from going from “idea” to “self-sustaining community” in less than 18 months.

The archive of the IRC chat where yesterday’s numerous announcements took place is available here. I’m sure it will be nicely summarized elsewhere by many others who are closer to the details.

There is a lot of interesting tidbits regarding TG and how it will fit into the greater Python web app ecosystem. If TG and its relation to WSGI, Pylons, Paste, CherryPy, etc. are remotely interesting to you, it’s worth a read.

My $.02: Moving forward, TurboGears is staying true to its original integration roots, by providing some glue, a tiny bit of magic, and the assurance that all of its component parts will mesh nicely together.

Howdy folks. I hope you have had a happy and safe holidays. Now it’s back to ye olde grind, so to speak.

I’m a little bit late to the game on the ‘07 predictions, but I’ll throw my $.02 in anyway

1) General Assessment: 2007 will be just like the latter part of 2006, only more so. Feel free to stop reading here if you’re pressed for time.

3) Trend Mongering: Nothing will want be referred to as “2.0″, (even this line item). Presence-enabled apps will be the Next Big Thing heralded in 2007, but don’t expect too much this year.

4) Technology Cynicism: “Enterprisey” will become an increasingly popular derogatory term among business and IT folk alike. At the same time, the technologies and best practices that really make solutions scalable and trustworthy will continue to go mainstream (e.g. ACID databases, rigorous change management, planning for concurrency, intelligent network monitoring, etc.).

5) Data Syndication: RSS/Atom will continue to creep into the BigCo IT mainstream. There may not be pervasive hands-on adoption in the next 363 days, but once management gets a taste of data syndication, it will likely show up in 2008 budgets.

6) Browser Wars: Mozilla’s XUL will become an increasingly popular app development platform, as XMPP4Moz and Firebug are very promising signs of things to come. Time to dust off those old ActiveX/Flash arguments from a few years ago.

7) Apple: The Mac will continue to grow in market share. Apple will probably do something cool and useful related to telephony besides an iPod/cellphone device. I’m expecting Mr. Jobs to explain to the world how antiquated telephones are, in a blindingly-obvious-in-hindsight sort of way. Oh, and one more thing, Leopard’s iChat looks like it will have an Answering Machine built in. My house has one of those too. For now.

8) Programming Languages: IronPython will continue to increase its influence on the Microsoft side of the house, championing the cause of dynamicism to the masses. TurboGears, Django, Rails, etc. will all continue to cross-pollenate good ideas and kick off the occasional flame war.

9) Databases: MySQL’s perception of dominance in the Open Source database world will continue to erode, as it faces the competition of SQLite from below and PostgreSQL from above.

10) DRM: Digital Rights Management has already started to generate a lot of bad press for Microsoft and Vista. I firmly believe that the folks from Redmond will listen to their customers and adjust their DRM and activation gameplans accordingly, so that content producers and consumers both get a fair shake.

In closing, DRM will probably be the biggest technology topic of 2007, as ordinary folks quickly start to realize that fast-talking, red Corvette-driving, Aqua Velva-drenched Hollywood types should keep their zircon-encrusted pinky rings off of computer hardware specifications, instead focusing their creative attention on much more important work: Snakes on a Plane 2.

Yes, I am referring to Rocketboom, which debuted on TiVo this week. It shows up on the “Now Playing” list just like any other show. Here, you have (relatively) low-budget video content showing up alongside mainstream TV programming as a first-class peer.

This is clearly a testament to RSS and its descendants (blogging, podcasting, whatever-we-end-up-calling-podcasts-with-video, etc.), and a sign of things to come for mainstream media in general.

If you have TiVo (and a broadband connection), here is more information on the Rocketboom Video Download Trial.

There was a bunch of news coming out of the Apple Worldwide Developer Conference (WWDC), but in my opinion, the story with the lowest “press-coverage-to-significance” ratio is around Apple’s iCal Server. It turns out that the server itself is written in Python using the Twisted networking framework.

Yesterday, it was also announced that Apple officially joined CalConnect, the calendaring and scheduling consortium. The iCal Server supports CalDAV, the up-and-coming standard for standards-based calendar and scheduling over commodity web infrastructure. For more info on CalDAV, check out this CalDAV article on NewsForge.
I find this interesting from three perspectives:

1. SMB Market Expansion: Apple’s movement into the calendaring space will provide another viable alternative to Exchange, especially for new businesses. Before WWDC, the rumor mill was buzzing about Apple getting into the Voice-over-IP (VOIP) business. I think that this is the classic Apple play: Take a useful technology that works, package it in an elegant interface, make it easy to use, and then cast the problem so that people say “Why didn’t it always work this way”. An easy to use Calendaring and VOIP solution from Apple would be a game-changing moment.
2. Ruby vs. Python: It puts some context around the announcement that Ruby on Rails will ship with Leopard (OS X 10.5). The bundling of Rails is great news for everyone involved. The Rails community is very much pro-Mac (all of the core commiters, and the vast majority of Rails developers work on Macs (much to the delight of Allan Odgaard, developer of the phenomenal TextMate text editor).

   However, the fact that Apple is building new, high-profile applications using Python should indicate that Apple is not likely to be a one-trick pony when it comes to dynamic languages.

3. Additional validation of Twisted: The fact that Apple is using Twisted as the foundation for something as strategically important as Calendaring should reinforce the well-deserved image and reputation of the Twisted team and the software that they produce.  In time, this is certain to introduce Twisted to the greater IT industry, and make Twisted-based applications much more interesting to the broader market.

Evidently, Scientists Have Identified Basic Principles of Communications. The theory goes that even though you read/listen one word at a time, your brain builds out a hierarchical tree of concepts, based upon its ability to group and arrange words and thoughts.

If you are at all a fan of O’Reilly’s Mind Hacks book, you’ll find the article interesting.

In the context of that article, here are two key reasons why ProjectPipe makes project data management easier:

• Everything in ProjectPipe can be managed as an outline. If your brain ultimately manages inbound communication as a hierarchy, then we’re saving the ol’ noggin a bit of work by setting up a tree-like hierarchy for your data in the first place
• Everything in ProjectPipe can be categorized with Tags. Tagging provides multi-dimensional data management without all the scary data modeling lingo. This is real useful for those cases where one or more pieces of data crosscut a number of discrete topical hierarchies in the larger, multidimensional “web of ideas”

While IANAPOLR (I am not a Physicist or Language Researcher), I’ll go out on a limb and suggest that presenting non-trivial information as an outline or hierarchy in the first place saves a great deal of the language parsing and structural encoding effort relative to the same information being presented in prose or a flat list.

In other words, organization accelerates cognition.

Hats off to the folks at 37signals for the Business Week cover story on 3/27. (From Signal vs. Noise.)

Jason and company at 37signals proved out the model that a small team can make a serious run at the hosted application space.

We don’t really see ProjectPipe competing with 37signals’ Basecamp. ProjectPipe and Basecamp are very different in terms of product vision and features, even though they’re both hosted project management applications.

(If you’re new to ProjectPipe, check out our ProjectPipe In Under Two Minutes video for a rapid-fire tour through our key features.)

Oddly enough, I met with a prospective customer last week that ended up choosing Basecamp over ProjectPipe for a startup that he is working on. The primary reason that he cited was that ProjectPipe seemed a bit too structured and process-centric for the 3-4 person team, whereas Basecamp seemed to “feel” more flexible.

We built ProjectPipe’s Project Management Trifecta process abstraction to minimize process-based overhead while still being able to pass muster with the Project Management Office (PMO) at the typical large company.

Therefore, the default configuration of ProjectPipe ships with the minimal set of suggested Documents in the process pages. We have built-in templates for a bunch of other documents, but they aren’t suggested in the default process content.

Needless to say, it took me a bit by surprise that even our minimal default set of documents and artifacts still seemed “too ISO 9000″ for said customer. This is a great example of the value of real user feedback early in the game.

We’re working on a preliminary set of “starter configurations” that you can use to expedite the setup of your project. This is built atop the code that we’ve been using for some time to do our in-person demos. This lets us instantly configure a demo to resonate with a prospective customer’s typical project (.NET, J2EE, etc.).

In the interim, if you’re evaluating ProjectPipe and it seems too structured (or not structured enough, for that matter) , please drop us a line at support@botonomy.com. We’ll be happy to show you how easy it is to customize any or all of the content to meet your needs.

]]>