Four Pillars: More on Nanny Languages

I’ve been thinking more about this ever since my last post on the subject, a whole day or so ago. And I remembered something I’d heard Clay Shirky say:

#3b. Good tools allow users to do stupid things.

A good tool, a tool which maximizes the possibilities for unexpected innovation from unknown quarters, has to allow the creation of everything from brilliant innovation through workmanlike normalcy all the way through hideous dreck. Tools which try to prevent users from making mistakes enter into a tar pit, because this requires that in addition to cause and effect, a tool has to be burdened with a second, heuristic sense of ‘right’ and ‘wrong’. In the short run, average quality can be raised if a tool intervenes to prevent legal but inefficent uses, but in the long haul, that strategy ultimately hampers development by not letting users learn from their mistakes.

OK, this was many years ago, at a time when the Web was still in its infancy. For those who are interested, the entire article is available here.

The value proposition of Collaborative Work and Wisdom-of-Crowds and Emergence and Blink and Serendipity are all in some way connected with Polanyi’s Tacit Knowledge definition, something we know but cannot articulate. Knowledge management specialists have forever been haranguing us with the Know what we Know, Know what we Don’t Know and Don’t Know what we Don’t Know triad.

And somewhere in that space is my concern about Nanny Languages. Shirky makes some key points in his article (published over eight years ago): the value of View Source, being able to see “on demand” how someone does something, how open and refreshing that is (Note to self: Is View Source a real patent, one that sticks to the meaning of patent?); the separation of site design from software engineering (yes I can hear the wailing and gnashing of teeth all the way here); the inversion of interface from Resides-In-Software-And-Is-Applied-To-Data to Resides-In-Data-And-Is-Applied-To-Software (more wailing and gnashing, I guess).

Life is about learning. We have to ensure that language does not restrict that learning. And nanny languages do restrict that learning, and will therefore atrophy over time. Or adapt to become less nannified.

By the way, it is worth having a look at what Clay says at the end of his article:

Furthermore, while there were certainly aspects of that revolution which will not be easily repeated, there are several current areas of inquiry – multi-player games (e.g. Half Life, Unreal), shared 3D worlds (VRML, Chrome), new tagset proposals (XML, SMIL), new interfaces (PilotOS, Linux), which will benefit from examination in light of the remarkable success of the Web. Any project with an interface likely to be of interst to end users (create your own avatar, create your own desktop) can happen both faster and better if these principles are applied.

Not bad for 1998.

Four Pillars: Time to rethink Frederick Brooks?

I’m going to be lazy and use parts of Wikipedia’s summary of The Mythical Man-Month. And make a few assertions as to why we may need to revisit the whole shebang. Yup, another very provisional post. More musing than thinking.

The Mythical Man-Month: When we develop for the web, are there really any more large teams working on monolithic projects? I guess that’s possible in some consultant-riven (yes riven not driven) public sector projects, but I’d rather not believe these are common. With social software, is there really an increasing communications overhead as you add people? Or is it a value-generating network effect, a real Power law? Does an opensource community working on an infrastructure component actually generate negative output at the margin? Which is the myth, The Mythical Mythical Man-Month or the (ostensibly) Mythical Wisdom of Crowds? Is democratised innovation a myth?

The Second-System effect: When you deliver little and often and you have active feedback and feedforward loops, is there really a second-system effect? Did Google or Skype or eBay or Amazon experience second-system effects? Or maybe they just missed that out, like the 13th floor.

Progress Tracking: If web development is about incremental daily delivery, are we reaching the stage where the cost of tracking exceeds the cost of delivery? Are projects becoming better, one day at a time? Can they? If Beta is now a recognised state, where is it on the progress map? Have we not already moved to a world where we work with constrained development team sizes and prioritised, dynamically allocated and re-allocated resources and deliveries? Where team size is a constant and delivery dates vary as needed? Where dates and real and politics are virtual? Where Prediction Markets define future progress.
Conceptual integrity: Is it really possible to separate architecture from engineering any more, and if so to what extent? Haven’t we already moved to a point where conceptual integrity is required at an ecosystem level, not at a system level?

The Manual: Hang on a second, let me get out my manuals for Skype and Google and eBay and Amazon and Firefox. Oops. Brooks meant reference and systems manuals, not “user” manuals. Let me get out my manuals for all the Writable Web applications we use where I work. Oops.

The Pilot System: That must mean Beta. The Google Beta. Is it really throw-away? How do you throw away a web app? No don’t answer that one, send me a postcard.

Formal documents: See The Manual.

Project estimation. Let me see. It will take one team day to deliver one team day worth of value, with deliveries prioritised according to market stimuli. When does a project start, when does it end? In today’s world, are these terms nothing more than tools to represent our actions in ledgers? And will we need that kind of representation if we stopped “capitalising” things?

Communication. See opensource movement. Global. Scalable teams. Social-software enabled.

The surgical team. See hacker.

Code freeze and system versioning. OK Mr Brooks, you win that one. Let’s keep it. Maybe we should call it community mores and values and modus operandi?
Specialised tools. OK we’ll concede them as well, except that we are now talking about opposable thumbs and machine tools and Because Of infrastructure.

Lowering software development costs: I love this one. I quote from Wikipedia: “Another technique Brooks mentions is not to develop software at all, but to simply buy it “off the shelf” when possible.” It’s now called opensource.

I’m only half-serious, but serious enough.

Generation M is not going to worry about the Mythical Man Month. They know the world revolves around the sun. How many people at Google and eBay and Amazon have read the book? [I’d really like to know].

Time to rewrite it. Because otherwise we face a different problem. We need to educate those that control and manage and check and monitor what developers do, otherwise a Little Mythical Man-Monthing can be a Very Dangerous Thing.

Four Pillars: Time for a Jailer’s Dilemma? Let the Games begin!

Wish I was a Kellogg’s Cornflake/Floating in my bowl taking movies
Relaxing a while/Living in style
Talking to a rais’n ‘cas’nally played LA
Casually glancing at his toupee

Simon and Garfunkel, Punky’s Dilemma

Love those lyrics, the meaninglessness of everything they portray. I have this image of the cornflake wearing sunglasses and a beret and a loud red shirt while floating in something that looks suspiciously like a director’s chair. And I really have no idea where the image came from, whether I’ve actually seen something reflecting this song graphically. But the image is there and real. As is the toupee on the raisin.
Good for Punky, whoever he may be.

Now. To more important (and potentially even more enjoyable) Dilemmas.

I think we’re fast approaching a time when we’re all going to have to learn about The Jailer’s Dilemma. [When I first wrote this I used “Gaoler” and then decided it was needlessly affected, would only reduce the number of people I communicated to, while “Jailer” conveyed the same meaning without the fuss and affectation. Was I wrong?]

Try and imagine a lock-in-practicising vendor. It’s not really that hard to do. Who is he locking in? You. Me. Us. So, at least for the sake of this argument, let me call such a vendor a jailer.

We have many jailers. And there are many of us jailed. The walls of the jails are made up of silo bricks, of IPR and DRM, of historical monopolies, of incompatible formats and standards and protocols. I’m sure there are more types of brick and of wall, but you get my drift.

We have many types of jail, with the type dependent on the nature of the brick. And we have the dubious distinction of being in multiple different jails at the same time. One of the unforseen consequences of digital jails is that you can be in more than one at the same time….

There are some forseen consequences as well. Moore’s Law and Metcalfe’s Law and Gilder’s Law and globalisation and disintermediation and the internet and the Web and telephony becoming software and commoditisation and virtualisation and collaboration and democratised innovation and opensource and The World Live Web and the Writable Web, all this has meant that the walls are less threatening than they used to be. There are holes and escape tunnels aplenty.

That’s why it gets interesting. There are lots of new dilemmas around. And they are different from the classic Prisoner’s Dilemma.

First, it’s not a zero sum game any more. The total number of potential prisoners is an increasing number.

Second, both prisoners as well as jailers can choose to defect or cooperate.

Third (and this is in common with more modern approaches to PD) memory is guaranteed and a core part of the game. What is different is that this memory is open and transparent and shared. An efficient market.

Fourth, there are different dimensions to cooperation or defection. Prisoners can choose to cooperate (or defect) with each other. Jailers can choose to cooperate (or defect) with each other. And prisoners can cooperate (or defect) in conjunction with jailers. And vice versa.

Fifth, we have external influences. Lawyers and regulators and governments are also in the game, inaugurating new jails (often) and shutting down old ones (occasionally).

Sixth, there’s a lot of money involved. A lot.

So where’s the payoff? What are the rules of the game? How do we get to equilibrium? What is the optimal strategy? Does Apple win by releasing their iTunes prisoners and going all the way with FairPlay? Does Microsoft win by providing Firefox and OpenOffice pre-installed? Can Sun do a Lazarus?

I have news for the jailers. The prisoners are cooperating. They are a market and a voice, a movement and a nation.

We may not have all the rules understood, we may not even understand the game.

But one thing is clear. Our intentions are known. The prisoners are going to win. Community-grown standards in a live ecosystem where freedom of speech and movement and exercising of intellect are sacrosanct.

So jailers beware. You can choose. Cooperate or defect. Don’t land up being the only ones in your jail. It gets lonely.
Suppose they gave a jail, and nobody came?

More later.

On Hackers and Painters and Education and Bonding and Risk and Nanny Languages

You may remember that in a recent post of mine, I linked to an essay by Paul Graham on What Business Can Learn from Open Source. Fascinating essay. I hadn’t read much of Paul since his LISP days, just the occasional wander over to his site. My bad.

Reading that essay made me go out and buy his latest book, Hackers and Painters. It’s not often that you get a book endorsed by people as diverse as David Weinberger, Chris Anderson, Larry Lessig, Andy Hertzfeld and Commander Taco. I had to buy it and read it.

I’m still reading it. Very. Very. Slowly. I like it that much. [An aside: Endorsements on book covers may be old-world ways of acquiring collaboratively-filtered ratings, but they do work. For example, I would read any book endorsed by John Seely Brown. Even a telephone directory.]

Why do I like Hackers and Painters that much? Here are a few extracts from the book (all in italics and judged to be “fair use”, annotated with some comments from me:

Paul on hackers:

What hackers and painters have in common is that they’re both makers. Along with composers, architects and writers, what hackers and painters are trying to do is make good things. They’re not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.

…………………

Sometimes what the hackers do is called “software engineering”, but this term is just as misleading. Good software designers are no more engineers than architects are. The border between architecture and engineering is not sharply defined, but it’s there. It falls between what and how: architects decide what to do, and engineers figure out how to do it.

What and how should not be kept too separate. You’re asking for trouble if you try to decide what to do without understanding how to do it.

My comments:

This is important. Too many firms, too many IT departments in firms, think everything is about process. Past-predicts-the-future assembly line. They get egged on by efficiency experts masquerading as consultants (or is it the other way around, and who cares anyway).

Software development is first and foremost a creative process, trying to find unique solutions to a firm’s unique problems. Those that aren’t unique problems can and will be solved by the opensource market, so contribute and participate, but stick to your knitting. Your job as an IT professional within a firm is to find those firm-unique solutions to firm-unique problems.

Take the creativity out of an IT department at your peril. Soon you will pay firm-unique prices to implement solutions to other people’s problems, not yours. Treasure your hackers. They’re like the nerds at school, more interested in being smart than being popular. Use kid gloves with them, there is a war for talent out there. And Generation M will make it even harder.

You want D-I-Y IT, treasure your hackers, they’re the only ones who care enough. Who stay up nights trying to figure out the best way to solve a problem. Who find those solutions that are appropriate to your firm.

You want Because Of IT, treasure your hackers. They are Because Of material.

Treasure your hackers.

Paul on smart kids and popularity and education:

Why are smart kids so consistently unpopular? The answer, I think, is that they don’t want to be popular…… [they wanted] to be smart. Not simply to do well in school, though that counted for something, but to design beautiful rockets, or to write well, or to understand how to program computers. In general, to make great things.

………………………….

The main reason nerds are unpopular is that they have other things to think about. Their attention is drawn to books or the natural world, not fashions and parties. They’re like someone trying to play soccer while balancing a glass of water on his head.

……………………………..

… I think the main reason other kids persecute nerds is that it’s part of the mechanism of popularity. Popularity is only partially about individual attractiveness. It’s much more about alliances.

…………………………………………

What bothers me is not that the kids are kept in prisons, but that (a) they aren’t told about it and (b) the prisons are run mostly by the inmates…… a world ruled by a caste of giants who run after a brown oblong ball….

My comments:

Again, some very telling insights. But Graham is not despondent, he recognises that we as adults, parents and teachers, can do something about it. The article on Why Nerds are Unpopular set off a whole pile of Searlsian snowballs around me. Why children from some cultures do so well at school, their will and wish to be smart rather than to conform to popularity. Why some children have the emotional intelligence to do this and others don’t. And so on and so forth.

What gets me excited is how much impact social software can have on this arena, as teachers and parents help children bond and collaborate, help children want to do beautiful and creative things, rather than just waste their lives wanting to be popular, and becoming miserable in the attempt.

Good teachers (and there are many) have had an uphill fight for many years, trying to get the talent they can see to become something, and watching that talent atrophy before their very eyes because of peer pressure and popularity contests and what Graham refers to as “court hierarchies”. But now we have tools to help the good teachers, tools that can help children bond and learn without the fear of the popularity contests.

This is worth a separate post sometime soon.

Paul on Risk and on Languages:

When I grew up, it felt as if there was nowhere to go, and nothing to do. This was no accident. Suburbs are deliberately designed to exclude the outside world, because it contains things that could endanger children.

………………………………………….

People sometimes send me mail saying “How can you say that Java won’t turn out to be a successful language? It’s already a successful language”…..When I say Java won’t turn out to be a successful language, I mean something more specific: that Java will turn out to be an evolutionary dead-end, like Cobol. This is just a guess, I may be wrong. My point here is not to diss Java, but to raise the issue of evolutionary trees and get people asking, where on the tree is language x? The reason to ask this question isn’t just so that in a hundred years our ghosts can say, I told you so. It’s because staying close to the main branches is a useful heuristic for finding languages that will be good to program in now…… I have a hunch that the main branches of the evolutionary tree pass through the languages that have the smallest, cleanest cores. The more of a language you can write in itself, the better.

My comments:

I think Paul is on to something here, although I quote from different parts of his book. It is something about Nanny States and Nanny Environments and Nanny Languages.

Human beings, yes this includes children, should never be insulated from risk. Trusting is all about risk. Bonding is all about risk. Learning is all about risk. Love is all about risk. Even faith is all about risk.
We need to empower everyone to take risk and be accountable for the consequences.

You remove the risk, you remove the accountability for consequences. And the incredible value that can be gained from that vulnerability.

I am not preaching anarchy. As a parent you have responsibilities for your children, as a leader you have responsibilities for the people you lead. But. You should be letting those “under your charge” find their potential, develop themselves to that potential and then exceed that potential. To dream dreams and see visions.

You have to discharge your responsibilities with care, but I don’t think you can do this by preventing risk, you do this by connecting risk with consequences and accountability for those consequences. And allowing people to take risk commensurate with their ability, that’s where the wisdom and leadership comes in.
So children do come off bikes and burn their hands and hit their heads on rocks. And they have to be allowed to, in order to learn. There are bikes and fires and rocks at work as well, and people have to be allowed to learn about them.

The important thing is to make sure that everyone is made aware of the likely consequences, and to take responsibility for those consequences.

In Nanny Environments, when something goes wrong, people look for someone to blame. Because they know it’s not them. Because we made it so, by removing risk and accountability.

And you can have Nanny Languages as well. Languages that prevent you from doing “wrong”, whatever that wrong may be. In the benighted belief that you should be stopped from making mistakes.

More later. Go read the book.

Four Pillars: Glimpses of Generation M

Sean pointed me at this post by Dave Morin. People who walk away from plum jobs because we won’t let them work the way we taught them to. People who expect to be able to IM and use internet mail at work. People who will expect to bring their own laptops to work, it is part of what defines them.

I was still getting over it, realising for myself that this Generation I’m busy preparing for is already here. Now.

And when I got home, I had a chat with Isaac, my 14 year old son, the upshot of which was that he’s going to upgrade digital cameras and I’m going to get his old one.

Yes, the Hand-Me-Up Generation is here. Now. And I am part of that Generation.

Generation M will hand things up to us, not wait for us to hand things down to them.