Although I have not been as in the flow of free software and
collaboration as I once was, my heart's still there. I'm still trying to find ways
to help myself and other people be less dumb and I believe that open software systems, granular addressability, persistent identifiers, the Church of Purple and the OnIt™ can help make it happen.

Articles Posted by cdent

Recent blog entries by cdent

A recent blog posting, The end of bosses, explores the trend of companies with flat organizational structures and little to no middle-management. It states that a key requirement for this style of organization is transparency of information:

The essential ingredients of peer management like trust, accountability, peer feedback, and decision-making autonomy rely on transparency of information. The problem with old school, hierarchical companies is that managers end up operating as obstacles for spreading information freely within a company.

I would argue that transparency of information is a requirement for any type of modern organization. We know that these days everyone can and will gossip on the grapevine using whatever media they can get their hands on. If incorrect rumor is at large incorrect actions will be taken. Better to have correct information out there in the first place.

The basic assertion here is that people use information in order to choose how to act and they will act on whatever information is available, even if it is incomplete or incorrect, even if they know it is incomplete or incorrect. The drive to act and react is sufficiently strong.

Choosing to be paralyzed, waiting on the defensive, is a commonly chosen action in response to incomplete information. It's no coincidence that "old school, hierarchical companies" have a reputation for being slow to act, slow to change and slow to get dynamic action out of teams in the organization. The teams are underinformed and disempowered from gathering and authenticating their own information. Without information they are left with three choices:

work slowly based on the small dribble of information they get

flail around chaotically hoping they don't get punished for it later

choose to do nothing, waiting

Flat organizations work well with information transparency because everyone is considered and empowered to be an authentic source of information. Vertical organizations must work much harder: The role of the manager must become solely that of information distributor and facilitator.

There's a Hacker News thread today pointing to a blog posting on Programmer Anarchy which itself points to presentation on the topic. It's fairly interesting. The basic idea is that the best way to get a job well done out of a group of developers is to give them a task, give them a customer and leave them alone. Agile stripped down to the bare essentials.

I tend to think this is (ought to be) fairly obvious stuff. Motivated people will collaborate effectively if they build the shared language, understanding and goals required to get moving. Once started on the right foot, they will move.

In 1986, SCRUM consisted of choosing an elite team of experts, throwing them into a room, and telling them to solve a problem with seemingly impossible goals. This unsettles them somewhat, but you persevere. You tell the team how they do it is their business. Your business is to support them by providing all the resources they need. Management is decidedly hands-off, so you leave them alone but give advice when asked. After a while magic happens, the team self-organises, and a product starts taking shape. Soon after the project starts a leader naturally emerges. As the project progresses, leaders change, because the initial leader may not have the expertise required in later stages of the project.

with this crucial follow up:

The problem is, in 1986 you talked about experts. What people have been trying to do lately, is to apply whatever methodology to average (or sub-average) developers and expect that the methodology itself increase substantially their productivity and the quality of their work.

But it doesn't work, simply because it cannot work. Buying a book on Agile/SCRUM/whatever is much cheaper than investing on the competency your team, and you simply get what you paid for!

Methodology can never make up for competence much like a requirements document can never make up for engaging in the real context of the customer or problem space.

There's been a fair bit of swirl around the internet lately about the latest draft of HTTP 2.0. The issues are several, with lots of disagreement from different camps:

It's too hard to implement.

It's too complex with that complexity focused on the wrong problems.

It's being developed with too much attention paid to the needs of a few large internet behemoths (notably Google, who are getting a bit greedy) where aggregate savings from shaving a few bytes here and there are huge.

James Snell has two excellent postings that cover some of the issues with robust technical detail:

Overall, I find all three proposals are focused on solving yesteryears problems, rather than on creating a protocol that stands a chance to last us the next 20 years.

Marco Tabini provides an example of many similarly themed postings which worry about the cultural impact. His, The 7-bit Internet, is aligned with my own concerns. He says:

Understanding how things work is a first—and important!—step towards using them well. When we don’t understand the tools we use, we are forced to rely on other tools to hide the underlying complexity and dumb things down to a point where they are manageable.

The concern here is that HTTP/2.x is going to be very challenging to inspect without additional tools. This means that the barrier to learning will be much higher with it than it is for earlier versions. You may think "oh it can't be that bad". If you're thinking that go and read Snell's postings a bit more closely.

Since its start the biggest win of the web has been the relatively low barriers to entry. It's always been quite easy for individuals and small groups without a lot of background or preparation to learn, to publish, to participate and to build. This is because the protocols, techniques and languages of content, configuration and code have often been relatively straightforward text that both people and computers can read with relatively low effort.

HTTP/2 takes a huge step away from this. It is a protocol that isn't easy for anyone or anything. It trades ease of comprehension for effective computation. This is a false win, a short term trade with damaging consequences that doesn't need to happen. Network bandwidth and computer power will continue to grow at astounding rates, but the human ability to engage in the social milieu of making and sharing that makes the web so awesomely diverse is fairly static. We want to encourage and enable that engagement and learning. The decisions we make about how stuff works impacts who will work with it.

Doug Engelbart passed away yesterday, 2nd July, 2013. His influence on and creation of the modern world was immense. He was my one and only hero.

In early winter 2001 I was taking time off from working to reflect and decide what to do next. I got a bit bored and decided that I wanted to learn something so enrolled in the Information Science program at Indiana University. I started with the Spring 2002 semester with a course called The Organization and Representation of Knowledge and Information.

This course was excellent because of instead of spending a lot of time on how we organize and represent we instead read, talked and thought about why. One of our papers was AUGMENTING HUMAN INTELLECT:
A CONCEPTUAL FRAMEWORK, written in 1962 by a guy named Douglas C. Engelbart. I had never heard of him. I was well past my 20th year of using computers and had never heard of him.

The first paragraph of the paper is worth quoting in its entirety (my emphasis):

By "augmenting human intellect" we mean increasing the capability of a man to approach a complex problem situation, to gain comprehension to suit his particular needs, and to derive solutions to problems. Increased capability in this respect is taken to mean a mixture of the following: more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex, speedier solutions, better solutions, and the possibility of finding solutions to problems that before seemed insoluble. And by "complex situations" we include the professional problems of diplomats, executives, social scientists, life scientists, physical scientists, attorneys, designers--whether the problem situation exists for twenty minutes or twenty years. We do not speak of isolated clever tricks that help in particular situations. We refer to a way of life in an integrated domain where hunches, cut-and-try, intangibles, and the human "feel for a situation" usefully co-exist with powerful concepts, streamlined terminology and notation, sophisticated methods, and high-powered electronic aids.

It took a while to digest, but that paper changed my life. After it settled in I wanted more. I read everything I could find about Engelbart. I found myself becoming an active member of various mailing lists associated with Engelbart and the so-called "Unfinished Revolution". My latent love of hypertext was rekindled. I was made hungry. I consumed information and created knowledge like never before. I wanted to get to the meta. Not make better things, not make things which make it easier to make better things. Make things which make it easier to think about making better things.

There on our board of advisors sat one Doug Engelbart. I first met him in his office at Logitech. We had some lunch, he showed me his mouse, chording keyboard and a working version of his Augment system. I told him how he and his work had changed my life's direction and given me a sense of purpose and poise that I had never had before. He made a joke about making an old man cry to cover that I had made a great man cry.

We didn't visit for very long but I am glad that I got the chance to meet the man who made a very big difference. We all feel the difference every day in the global world and I feel it every day in my own local world. His presence will be missed but his inspiration will live on.

Part of the series of notes tagged why or book describing why I do what I do and what it is that is being done. This is transcribed from notes taken during a solo meal.

In a basic way, what I've been trying to do since I was a system administrator at an ISP in the mid 90s is create technologies (tools and processes) which allow and encourage information empowerment: Being empowered as a result of having information.

The idea is simple and egalitarian: If people, any people, have access to information about a context they can participate in that context in a meaningful and postive way.

This implies a responsibility: All the participants in the context must be creating external, relevant and lasting artifacts.

They must write.

So that others can read.

And write again.

These contexts are not just open by default but also inspectable and discoverable by default.

(In such a context only those things which actually are secret should be secret. Individual artifacts should be protected, not an entire corpus. This is actually safer because such artifacts are far less vulnerable to errors of transmission: the artifact protects itself.)

Artifacts which are easy to access and granular to access are more amenable to action and composition by partners and potential partners than vast documents. Though not everyone will participate everyone can.

The motivated self select to participate.

We can conclude that if we want autonomous team forming, then we must have transparent information availability. People find one another via information.

In a progressive information environment, communication (the creation and distribution of information artifacts) is a primary responsibility, never overhead. Being an effective reader, writer and information tool user is critical. A refusal to read or write is not acceptable. Voice is not a suitable substitute for the lasting artifact of writing. Voice is not only selfish (because of its locality in time and space) it also prevents reflective response.

Voice, of course, has its places, especially for brainstorming, but those not present in time or space must be remembered. Persistent artifacts must emerge.

The progressive information environment encourages innovation because people are able to learn a great deal about the environment. This includes, importantly, the existence, nature and accessibility of problems. Problems anyone can help to solve because they are visible.

Arrogating perfection, passing the buck, hiding from reality (common behaviors in the command and control environment) stifles, with relentless gravity, the natural tendency of anyone to want to improve their environment. Transparent information is honest, open and inviting about opportunities for improvement. Accessible information recognizes that expertise can be found anywhere.