Adam Bosworth's Weblog: KISS and The Mom Factor

Adam Bosworth's Weblog: KISS and The Mom Factor
KISS and The Mom Factor
My new role (I recently moved from BEA to Google) has me working on very different types of software. Rather than worrying about what the IT of large corporations needs to do to support the corporation, I'm worrying about mere mortals. In fact, my Mom. I never find that I can build any software if I don't first get some mental image in my head of the customers. Who are they? How do they look, feel, think? I call this designing by guilt because if you don't do what feels right for these customers, you feel guilty for having let them down. Of course, customers are endlessly disparate, complex, heterogenous, and distinct. But even so, I've always found it necessary to think about a small number of distinct types of customers, and then design for them.

And boy is it satisfying to do this when the people you are designing for are your friends, family, relatives, your smart alec son, and so on and when even your mother can use what you build. I call this the mom factor. It is corny but fun.

It is interesting to me how this focus around simplicity in the services world could carry through even to the plumbing people use. For example take so called web services. The original impetus behind XML, at least as far as I was concerned back in 1996, was a way to exchange data between programs so that a program could become a service for another program. I saw this as a very simple idea. Send me a message of type A and I'll agree to send back messages of types B, C, or D depending on your A. If the message is a simple query, send it as a URL with a query string. In the services world, this has become XML over HTTP much more than so called "web services" with their huge and complex panoply of SOAP specs and standards. Why? Because it is easy and quick. Virtually anyone can build such requests. Heck, you can test them using a browser. That's really the big thing. Anyone can play. You don't have to worry about any of the complexity of WSDL or WS-TX or WS-CO. Since most users of SOAP today don't actually use SOAP standards for reliability (too fragmented) or asynchrony (even more so) or even security (too complex), what are they getting from all this complex overhead. Well, for one, it is a lot slower. The machinery for cracking a query string in a URL is about as fast as one can imagine these days due to the need services have to be quick. The machinery for processing a SOAP request is probably over ten times as slow (that's a guess). Formatting the response, of course, doesn't actually require custom XML machinery. If you can return HTML, you can return XML. It is this sort of thinking that being at a service company engenders. How do you keep it really simple, really lightweight, and really fast. Sure, you can still support the more complex things, but the really useful things may turn out to be simplest ones.

You have to. The scale is orders of magnitudes more than is normally processed by a business process within even the largest corporation. It is hard enough to build these massively scalable services if you keep the moving parts simple, clear, and down to a small number. This is usually called the KISS principle as in keep it simple and stupid or, more rudely, keep it simple, stupid. It reflects the engineering realization that just delivering on the required speed and scale will require a lot of plumbing and monitoring as it is.

So, I'm having a lot of fun learning about a whole new world.
Trudno sie z tym nie zgodzic...