Does PEAK do too many things?

You wouldn’t think that having too many features would be a problem, but maybe it is. Somebody just asked a question about testing on the PEAK mailing list, and as part of my response, I told them about peak.ddt, a FIT-like framework for “Document Driven Testing”. Implemented using peak.web, peak.ddt has a variety of tools that can be used to create tests on peak.model domain models and peak.storage.SQL database queries.

Of course, since it’s based on peak.web, that means it’s actually a WSGI application that can run in any of PEAK’s three WSGI runners, including its highly-configurable, very scalable pre-forking FastCGI process supervisor. Let’s not even get into the command-line apps framework, event-driven programming framework, the domain model framework, the UML processing, configuration system, extensible URL handling, and the “peak n2” SQL/Python shell.

I could sit here all night linking to posts explaining other major features and frameworks that lurk just beneath the surface of PEAK, but you probably get the idea already. PEAK is basically to Python what J2EE is to Java, except that it’s not nearly as finished or polished, despite two years of part-time work on my part. Nonetheless, it’s already an impressive piece of work, and some have expressed surprise that it’s mostly the work of one person.

However, I wonder if its own prodigous scope will ultimately be its undoing. Will people avoid it because there’s “too much to learn”? Tutorials like the IntroToPeak probably help some, but I sense more that it’ll be an issue with “marketing”. If people hear “oh, you should use PEAK for that” for too many things, they’re likely to tune out or be turned off: obviously something that does so many things is hard to learn, right?

They’d be wrong, of course, because most frameworks in PEAK are built on top of just a few core frameworks, so once you’ve grasped a few essential concepts, you should be free to explore only the pieces you need. In practice, of course, you’ll be stopped short by the current lack of documentation apart from reference docs, the two half-finished tutorials, and the mailing list archives.

The big mistake I made before was to have the documentation reflect the structure of the system itself. That is, I tried to write tutorials that built up from fundamental concepts to more advanced ones, step by step. This resulted in documentation that was correct and detailed, but which most people hated. The IntroToPeak tutorial that R.D. Murray created shows the right way forward: examples based on simple functionality that doesn’t get in the way of showing how the architecture works.

But I’ve digressed from the marketing point, which is this: brand extension sucks. If your brand stands for everything, it stands for nothing. J2EE is a brand for managers, not developers. The developer brands in Java are called JDBC, JNDI, EJB, JSP, Servlets, and so on. PEAK lumps all the various corresponding things into subpackages, and we brand the whole thing PEAK, making it impossible to tell anybody in a sentence or two what the heck it is.

Given that PEAK exists primarily to scratch my own “Python Enterprise” development itches, I don’t suppose a lack of marketing clarity is too much of a problem. Still, it’s interesting to think about.