Open eyes Working brain

So, Google is going to kill Wave.

But despite these wins, and numerous loyal fans, Wave has not seen the user adoption we would have liked. We don’t plan to continue developing Wave as a standalone product, but we will maintain the site at least through the end of the year and extend the technology for use in other Google projects.

That’s a great example of why “do one thing well” is better than “do it all”. Not only because, as Gall’s law implies, it’s easier to get a simple system straight, but also because once you get a complex system straight, you still have to make people get their mind around it. Wave made chat and e-mail play well together, with a great replay feature, bots and translation. Twitter gives short text updates. Adoption declared the winner, but we already knew it.

Having recently read RESTful Web Services, i wanted to write about the most interesting of my REST-induced epiphanies:

Form based authentication with its login/session/logout workflow, which is currently dominant on the web, is hopelessly broken.

To understand why, one has to grasp how the greatest living RESTful implementation, the web and its backbone protocol HTTP, was meant to work. In a nutshell, there’s a server that keeps the state of the web application, split into meaningful resources. Each resource has its own name (URI) and a set of available representations of itself. That’s all the server knows. Then there’s a client that acts as a finite state machine visiting resources, getting representations and then moving to other resources through links and forms. The state of the conversation, the session, where a client has been and where it is now, is something that belongs to the client. Server drives the client by feeding him a graph made of states and links to other states, but it’s the client who is in charge of following a path. That’s statelessness, the simplifying property that made the web triumph as a darwinian winner.

In this view, authentication should have been largely a client-side business.
The client visits resources anonymously. If it wants to be authenticated, it just starts sending authentication data with each further request. If it wants to be anonymous again, it just stops. It could as well send a mix of authenticated and anonymous requests.
The server doesn’t care of what happens between requests. If a single request carries authentication data, it checks the data and possibly replies as if the client were authenticated. If a request has no authentication data, a generic response is returned. There’s no server-side login through a form, there’s no server-side logout, and above all, there’s no temporal ordering between those two and hence no server tracked session. All of a sudden, the beauty of this comes with great force. By delegating authentication to the browser using the standard HTTP mechanism we can greatly simplify application code.

Unfortunately, in reality this is not the case. During its race to the top, HTTP lost part of its original vision, mainly due to implementation mistakes.

1. The specs failed to hit the sweet spot of authentication security. They standardized Basic Authentication which, by sending user and password in plain text, scared people to death and Digest which, due to its complexity and required server cooperation, never really caught on. A client-side mechanism with cheap yet reasonable security such as WSSE UsernameToken, later adopted by atom, would have been optimal.
2. Browsers took away login from client’s hands by showing the popup dialog to input user/password only after a 401 http error code from server. There should have been an always visible “login” button since the specs said “A user agent that wishes to authenticate itself with an origin server–usually, but not necessarily, after receiving a 401…”.
3. Browsers practically took away logout from client’s hands by requiring to close the browser in order to clean the passwords cache. There should have been an always visible “logout” button.
4. Browsers gave no chance to customize the ugly and annoyingly modal login dialog. HTML and/or CSS could have been used.
5. Browsers gave no client-side storage needed to keep session data but again turned back to server with cookies. They should have given something like upcoming HTML5 localStorage and sessionStorage.

Now there’s not much that can be done short of a collaborative effort by all browser vendors. Meanwhile we can keep dealing with authentication in application code on the server, in a never ending pile of custom solutions, each one slightly different, for yet another pretty standard problem. A problem solved 15 years ago.

If i had to award the best talk at GTAC 2009, the no-brainer choice would be Prof. Niklaus Wirth opening talk. That’s not surprising if you consider who the speaker is, one of the great pioneers of computer science in the field of programming languages. What’s most surprising to me is that he presented a (pre)historical review of problems which turned out to be incredibly relevant today and, somehow, forced me to reframe my understanding of testing.

Building on 1972 Dijkstra dismissal of software testing

program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence.

Wirth explained that testing is treating symptoms instead of the disease, with the disease being our failure to prove correctness of programs by analytical means. This failure has its roots in distant past but it still holds today with languages and tools too complex and unreliable. Languages and tools providing proper abstraction, really hiding the system beneath, would give us the simple and rigorous ground to make programs easy to prove correct, so that no testing would be needed. Unfortunately, this looks far from happening

Programming languages are further from being mathematically nice than they were 50 years ago! They’re huge and complicated. They contain big libraries, and most of a programmer’s time is spent finding and learning the right libraries.

and again

What progress has this field actually made? We still struggle with the same problems as 50 years ago: iteration times, debugging, scratching our heads trying to figure out what went wrong.

How insightful! Empirical evidence that computer science made no sizable improvement in software construction is everywhere. It’s like a hamster in a wheel, running nowhere. Why is that? Maybe, we’ve been piling leaky abstractions on leaky abstractions, apparently hiding information without really simplifying, to the point where progress is drowning in complexity.

Testing is a nice way to easily lay down executable specifications, yet it requires maintenance and quickly degrades as we try to cover more cases. But when we code we have the chance to write self-describing programs which are executable specifications, reducing the coverage of tests needed, ideally to zero.

What does it mean in practice? Whenever it’s possible one should aim at declarative code. Domain specific languages and functional programming come to mind. The point being, if a program matches closely its specification, what’s left to test?

def factorial(n)
    if n == 0
        1
    else
        n * factorial(n-1)
    end
end

It’s becoming clear to me that a programmer is probably closer to a craftsman than a scientist. The craftsman greatest strength is mastership of his tools. So just as the carpenter masters the plane to shape wood, the programmer must master a text editor to shape programs. I’ve spent enough time wandering aimlessly around a lot of editors and IDE’s. It’s time for me to settle down, make a competent choice and take the years needed to become proficient in it. I wanted something possibly simpler, light and which would leave me in control. That means an editor over an IDE, but which one? I did some deep research and after an endless stream of positive reviews backed by Gabriele “warm” suggestion, i bought “Learning the Vi and Vim Editors 7th edition”. Vim is 1991 software based on a 1970s one, and it’s great. Btw my second best was emacs, another 1970s software. This must say something about advances in text editing software industry. Anyway, now that i’ve finished the book and daily using Vim, i realize its very existance is relevant to the “simplicity in software” debate.

Is Vim amazing software? Yes. Is Vim simple? No. This could imply that simplicity is a highly overrated software value, but i think it’s not. It just implies that, as any other thing under the sun, simplicity is a relative value. Relative to what? I guess to user’s knowledge of the domain. Let me explain.

Simple software is one that provides a few objects and a few rules to compose those objects coherently into newer more complex abstractions. This makes an optimal hotbed to learn. Few objects are easy to understand and remember. Few corner case free rules give confidence while exploring the unknown. It’s important that the learner is not exposed to further possibly useful complexity which is not ready for yet. Only some to ignite inspiration, but greater power cannot come a priori, but as a consequence of greater understanding of the domain. This way user and software evolve together.

“Good” Complex software, which still tries to minimize basic objects and rules and completely avoid corner cases, may ship equipped with many levels of abstraction relevant to the domain. That’s for the sake of efficiency, so that the skilled user will be able to manage complex scenarios by quickly referring those abstractions. Give something too simple to the master and he will end up bored and unproductive. Give something too complex to the apprentice and he will run away confused.

Vim is extremely good and complex software which comes with a plethora of short keyboard commands to make any conceivable manoeuvre on text at top speed. Optimized for being efficient with keyboard, which already happens to be the most efficient input device, usually much better than mouse. That’s heaven for touch typists as i am. The nice thing about efficiency is that it can be easily quantified by time. Same goal, the faster the better.

Let’s close with a fulgid example of vim capabilities with a common editing pattern: swapping two words.
An usual hybrid keyboard/mouse approach on windows:

• Select the first word (click/drag the mouse or double click)
• Cut (ctrl+x or right click and use menu)
• Move the cursor after the next word (move the mouse and click)
• Paste (ctrl+v or right click and use menu)

I guess it takes 3-4 seconds to complete correctly

Vim keyboard based approach:

• type dwwP

An average good typist can do 50 wpm which means it takes about 1 second to type 4 characters. That’s efficient.

The more i read about psychology the more i feel it’s compelling knowledge to anyone especially in the software business.

The Paradox of Choice by Barry Schwartz is enlightening on this respect. Humans inherently crave control, autonomy, self determination and so choices which are natural means to express this essential demand of freedom. Yet, humans used to have simple lives with limited amount of choices. Now, in these days of exponential growth and exploding options, they just can’t cope anymore. They’re overwhelmed by escalating possibilities in all fields of life ending up paralyzed, frustrated, dissatisfied if not plain depressed.

Schwartz comes to the conclusion that, to relieve distress, they have to fight back their inner impulse and learn to accept some constraints are good, that simplicity, more often than not, can be the golden path to well-being. In a later talk at Google, he goes as far as pointing out that software/product makers should embrace libertarian paternalism, which in a nutshell means: give them choices but also apply soft contraints to ease their path to “good” decisions. Those that will probably make them better.

Greek Diners in New York City. Their menus are about a thousand pages. There is no dish anyone has ever eaten it isn’t somewhere on those menus and tucked in the front cover of the menu there’s a little piece of paper with “today’s specials” – four or five items. Inadvertently you create an insoluble problem by giving people 10,000 things to choose from and then you solve it for them by giving them today’s specials and people are driven to choose, take your advice, take your recommendation.

This sheds new light on the company vs customer, simple vs full featured software picture i’m still trying to figure out. As Don Norman puts it “People want the features” and “Features win over simplicity” and as Joel Spolsky notices “With six years of experience running my own software company I can tell you that nothing we have ever done at Fog Creek has increased our revenue more than releasing a new version with more features. Nothing.”. That’s obvious. That’s what people naturally do, the way society drives them to do: Manifest control by claiming more options, more variety.

But then there’s the other side of the coin. Many of them will reject using such software or at least defend themselves by restricting to very basic usage and, in the end, they’ll feel bad about it. Empirical evidence is already there in stats about unused features. People also seem to feel it as the great success of “for dummies” books and simplicity buzzword in advertising underline. Using Schwartz words:

A majority of people want more control over the details of their lives, but a majority of people also want to simplify their lives. the paradox of our times.

Customers bombarded by never ending stream of choices and responsabilities are to me much like children in need of a good parent. So companies as anyone really or virtually in charge of other human beings are subjected to the same old ethical question:

Do we care for us or for them?

Are we in the business of making money or in the business of making happy customers?

If you like me value the latter, then maybe, it’s time to start acting as a lovely father who takes best choices for his offspring but as they grow safe, empower them day by day. Instead if money drives your actions, i just got one more question for you:

Do you think such economy is REALLY sustainable?