lesscode.org

This is what extremely powerful looks like. This is what extremely powerful is like.

Gates had this to say in a recent interview with Jon Udell.

“There’s only really one metric to me for future software development, which is — do you write less code to get the same thing done?”

I’d be lying if I said that didn’t put an immediate grin on my face.

I personally don’t get that feeling from Microsoft’s present toolset but I’m interested in understanding this situation better. I’ve been impressed by their ability to resist being sucked into much of the Enterprise hype that seemed to drive J2EE to bloatedness, but “less code” as the metric for innovation in development tools and methodology? Is there really a strong concious regard for simplifying things in Microsoft’s developer culture?

I’ve had this in draft for a few days because I wanted to talk a bit about the false assumption that GUI = simplicity (not saying that’s what is going on here but it is a falacy MS has subscribed to in the past). But now Michael Champion, who is one of the very few reasons I have left to respect MS’ technology, is beating up on us for a comment.

So bravo to Gates and all that but is it true and does Gates’ personal view on simplicity trickle down into the trenches at MS?

Via Tim.

I’ll take it as a given that if you’re reading this then you agree that, for the sake of sanity and productivity, it’s time coders gave up on roll-your-own, and moved over to modern frameworks where one can concentrate on business logic rather than request parsing (and get all those AJAX goodies for free ;-) ).

I’ve been looking on with interest for the last year and a bit, and as I’ve watched the pioneers blaze their XP, RoR, lesscode trail across the web-firmament, I’ve begun to suspect that I must have missed something. Yes, it’s powerful stuff, and yes it isn’t all smoke and mirrors - there really is “gold in them thar hills…” - but, and for me it’s a big but, we seem to be missing the big picture. Where are the map makers? Where’s the documentation for the second (or third) wave?

Self-documenting code is all very well, and having a common vocabulary of design patterns helps when discussing solutions to individual problems. But what second-wavers really need (and I include myself here - no, actually, put me down as a third-waver) are more pictures. More exposition. Road maps.

Is there a way to add XD (eXtreme Documentation?) back into the XP mix? Writing elegant code is hard, and people who do it earn the admiration they received. But I would argue that writing good documentation is harder, and that it shouldn’t be left for the second-wavers to do.

People who’ve moved to XP have already gone thorugh the pain barrier of

• write the tests
• then write the code
• (then refactor)

and have proved that in the long run, it means better code, less debugging, in less time. But having proved that that works, might there be some benefit in switching to;

• write the spec
• then write the tests
• then write the code
• (then refactor)
• then write an overview!!!

Might this result in (my h-nought) more easily modfied code, quicker adoption by other coders, greater community support?

I’m genuinely interested in other people’s views on moving documentation down(?) the food-chain, so that it’s non-optional, and as integral to writing new code (and frameworks) as writing good tests. Yes, there are good auto-doc tools and methodologies out there, but that right now they still seem to be seen as secondary to the process by Joe Frontiersman, and they only deal with what’s in the file, not what’s in the coder’s/architect’s head. (There’s the nine diagrams of UML, yes, but who on the bleeding-wrist of open-source technology is actively using/sharing designs via UML?)

Let me know if I’ve missed a trick somewhere.

[A few thoughts for the pot: I believe the that the reason the Open Source model works because it’s based on non-coercive collaboration. But Source Forge is littered with unfinished, half-baked projects because someone didn’t think to check that there wasn’t already a project out there that they could use. (How many PHPUnits does the community really need?) Should there be a ‘requirement’ for documentation before a project gets listed? Perhaps it’s time for ‘ideaforge’, or ‘architectureforge”?]

Rather than reinventing everything or trying to clone some other framework, TurboGears takes advantage of the great tools that are already available!

The tools:

• MochiKit is a clean and powerful JavaScript library.
• Kid is a designer- and programmer-friendly template system… written by lesscode’s fearless leader.
• CherryPy
• SQLObject

A significant problem in the trenches for Web Services isn’t the ability to play nice or not with existing Internet protocols, or its complicated type system, or Object/XML impedence. It’s optionality. When you get down to it, too much in Web Services is optional. Calling the specs composable and thus dressing that up as feature is pointless - optionality is a curse. Yes, WS specs are designed to be composable, but this underplays the fragmentation costs of not having an interoperable core.

Optionality here means: a) the state space for communications is huge , b) everything has to be negotiated, c) no clear layering resulting in dependency issues. These introduce complexity and thus drive up costs. As a result I disagree that implementing something like WS-Eventing is “simple”, exactly because there is freeform composition. And that’s just WS-Eventing. What about addressing, transfer, policy, wsdl, faulting, the various reliable messaging approaches? The list goes on and on. Even the basic SOAP stack seems to be difficult to get right; we’re on the third generation inside 7 years of what is supposed to be stable computing infrastructure.

Favouring optionality can’t possibly be a good idea for protocols, or even protocol frameworks like SOAP. In that sense RSS or Atom have more interop potential, precisely because they take options away by design, even though they wouldn’t present an obvious choice for mainstream enterprise purposes.

Ur-Protocol

Here’s Elliotte Harold and Ted Neward arguing over the merits of HTTP as a Highlander Protocol.

Elliotte:

“Web Services Addressing is trying to define an addressing scheme that can work over HTTP, SMTP, FTP, and any other protocol you can imagine. However, each of these protocols already have their own addressing systems. Developers working with these protocols don’t want and don’t need a different addressing system that’s marginally more compatible with some protocol they’re not using in exchange for substantially less compatibility with the protocol they are using. Besides nobody’s actually doing web services over anything except HTTP anyway. Doesn’t it just make more sense to use the well understood, already implemented debugged HTTP architecture for this instead of inventing something new? “

Ted:

“No, it doesn’t. There’s no sense in trying to take bits that were designed for a distributed hypermedia system (Fielding’s words, not mine) and trying to bend it to fit a problem space that isn’t distributed hypermedia. Can we learn from the REST architectural style? Absolutely–and the new WS-* specs, including SOAP, do exactly that, favoring self-descriptive messages over RPC calls as the principal abstraction to deal with. But does that mean we tie ourselves solely to HTTP? Oh, hell no.”

The problem with using HTTP as the Highlander protocol has been described best by Marshall Rose:

"HTTP has become the reuse platform of choice, largely because:
 - it is familiar
 - it is ubiquitous
 - it has a simple request/response
 - it usually works through firewalls
These are all good reasons, and - if HTTP meets your communications requirements - you 
should use it. The problem is that widespread availability of HTTP has become an excuse 
for not bothering to understand what the requirements really are. It's easier to use HTTP, 
even if it's not a good fit, that to understand your requirements and design a protocol 
that does what you really need."  

HTTP bias aside, sometimes you do have to work across multiple protocols. That results in the problem of managing and preserving addresses and message identity. And when you do have to span protocols and systems for messaging purposes, especially where there are multiple self-interested administrations, you want to have a standard envelope that provides at minimum a means of identifying the message, the sender, the recipients, and probably time stamping. Some kind of ability to correlate messages. These are baseline criteria - without them you’re toast. You need standard headers not just for routing traffic (important) but because you need to know what the heck is going on operationally - you want a standard means of asking the various endpoints (or nodes, or gateways, or hubs, or whatever you want to call them) questions. Where is my message? How many messages did you drop? Which messages did you drop? When? Whose messages are you dropping? Will you resend this message? How many messages have you sent to so and so? What open items do you have? And so on. However WS, and in particular, SOAP, doesn’t provide a standard (as in non-optional) set of headers and thus it doesn’t provision this kind of generic communication facility. I’ll confess that this has never made sense to me, given SOAP’s protocol framework and inter-systems ambitions.

Ted has a specific rant about broadcast and push being unsuitable to run over HTTP. I don’t think there’s any argument that, formally speaking, HTTP is not the right protocol for those jobs. But here’s the kicker. Blogs and RSS syndication are exactly that, done over HTTP infrastructure. The world has not gone running to push RSS over XMPP because there is obviously a scale problem when you draw things out on a napkin. [Which is not to say this writer wouldn’t like to see more Atom over XMPP; it’s clearly a good idea. Nonetheless the Web sky is not falling in yet. ]

And even in the push scenario, what’s the point of a protocol framework? Why not use XMPP for push/pubsub? Does this mean when people on the ground start getting Eventing systems and EDAs built out over commodity IM, can we expect to see another rounds of the “It’s Not Sufficient” meme played out again, this time for messaging protocols?

What now for SOAP?

If you want to span systems asynchronously in a manageable fashion you’ve got to have standard models for addressing and identity baked in. These are not optional if this stuff is expected to work. It’s taken some time for the WS community to get round to dealing with addressing and naming, but this is key stuff for getting something done over a gateway and for me, SOAP’s value is largely in dealing with gateways asynchronously. Addressing being an optional add-on to SOAP is quite strange then, although now that it exists that’s good news. Down the line then what would be useful is a subset and hardening of SOAP; a 1.3 revision where WS-A and some key message headers are non-optional.

WS should be starting out with, and not ending with, profiles like RAMP.