Recent blog entries for cdent

15 Oct 2013 (updated 16 Oct 2013 at 17:11 UTC) »

Information Transparency

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.

Syndicated 2013-10-15 12:12:43 (Updated 2013-10-16 17:10:51) from cdent

17 Jul 2013 (updated 8 Oct 2013 at 17:10 UTC) »

Programmer Anarchy

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.

There's a comment on the thread containing this:

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.

Syndicated 2013-07-17 11:32:13 (Updated 2013-10-08 16:35:02) from cdent

11 Jul 2013 (updated 8 Oct 2013 at 17:10 UTC) »

HTTP/2 Missing the Mark

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:

Poul-Henning Kamp, the Varnish guy, has a well thought out response in which he explains:

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.

Syndicated 2013-07-11 12:48:05 (Updated 2013-10-08 16:35:49) from cdent

11 Jul 2013 (updated 8 Oct 2013 at 17:10 UTC) »

Heroes

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.

A few months later I joined with Eugene Eric Kim to form Blue Oxen Associates, a high performance collaboration think tank inspired by the work of Doug Engelbart. We established the Blue Oxen Way, built PurpleWiki and engaged with groups of all sorts wanting to do better.

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.

Syndicated 2013-07-03 20:59:01 (Updated 2013-10-08 16:36:44) from cdent

11 Jul 2013 (updated 8 Oct 2013 at 17:10 UTC) »

My Point

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.

Traditional management filters information for safety and control. Effective management filters information for feedback and guidance. Leadership is responsible feedback.

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.

Syndicated 2013-04-13 16:11:27 (Updated 2013-10-08 16:36:27) from cdent

Federation is Sad

I spent a brief amount of time recently checking up on the state of so-called federation on the web. In part this was while thinking about MTC but also while learning about (and implementing an experiment of my own) distributed hash tables.

The web, at large, is distributed. Content is in this giant graph with many nodes. A URI identifies some atom of content in the graph. Some atoms link to others. This simple model has expanded information exchange enormously. The last twenty years or so has had a lot of zOMG.

At various times throughout those twenty years, sometimes some branches of the graph have more nodes than others, creating an apparent imbalance. These days Facebook has a lot of the nodes. While technically this does not violate the distributed nature of the web, it adjusts the human experience to such an extent that some people can think of Facebook _as the web_.

To combat this people come up with the idea of federation: create content somewhere and copy it to one or more other places. For example create a message on status.net and have it duplicated on twitter and facebook.

This makes my inner geek cringe: federation makes copies of things. This is wrong. Surely we should be distributing URIs? Copy by reference not by duplication!

If that happened you can imagine a considerably more distributed web: Rather than publishing something to a service, you simply put it into a distributed hash table network storage service, and get back a URI. You don't know where the content is, only that it is out there somewhere. Then you give the URI to systems that can display or otherwise manipulate the content, by reference.

Keen!

Unfortunately people aren't excited to make this sort of thing work because:

  • they worry about latency
  • they are addicted to search
  • they are addicted to control

So they return to federation as the next (but distant!) best solution.

And that is sad.

Syndicated 2012-11-04 15:07:45 (Updated 2012-11-04 15:08:08) from cdent

30 Jul 2012 (updated 30 Jul 2012 at 22:12 UTC) »

20120730

Created tsapp to display, in a very basic way, the functionality available via the tsapp tool that I've been creating over the last few days. It worked really well.

There are a few issues but for the most part the concept seems sound and the implementation simple enough that it doesn't make my ZOMG complexity! Run! reaction kick in.

One open question: Should it allow user registration and space creation? At first glance this seems a step too far, we'd want people to have understood what TiddlySpace is before using tsapp. But perhaps this is wrong, maybe tsapp is a vector for new (technically oriented) people to enter the ecosystem?

Another issue is how to deal with an app that is designed to be included or uses "extra" bags. Is special support for that needed? Or can that be worked around.

It may be useful to compare what was created and what was discussed. The discussion described the form of an app and the process of app creation. The form of an app is mostly the same between the two. The major difference is that at the moment tsapp has no facility for pushing to "optional additional bags". You can proxy to those bags, but when tsapp push is run the content goes to just one bag. It may be worth considering a way to map assets to different bags (presumably by pathname).

The discussed app does both push and pull. The created app only does push. Implementing pull assumes there are situations where the server is authoritative for content. Either the local dir or a git repo ought to be authoritative. Also GET is the easiest of the methods, so curl can be used in a pinch.

The discussed app planned "reliable algorithmic transformation" of paths to allow content both local and remote. The built app goes for a much simpler solution, that seems to cover most common cases. So, in fact the "overkill" solution was the simple one. Largely because WSGI is awesome.

Syndicated 2012-07-30 19:47:47 (Updated 2012-07-30 21:33:12) from cdent

28 Jul 2012 (updated 28 Jul 2012 at 21:12 UTC) »

20120728

I have upgrade my notebook to Mountain Lion and in the process seem to have rather messed up my development environment for Python. Haven't yet figured out where I went wrong, but merely upgrading Xcode does not fix it.

The problem appears to be a mismatch between workarounds that packages like Python-MysqlDB do to cope with where OS X puts include files and new places where such things are in Xcode 4.4. In addition to installing the command line tools (from within the Xcode preferences (Downloads), my solution:

cd /System/Library/Frameworks/Python.framework/Versions/2.7/include
su mv python2.7 python2.7.orig
sudo ln -s \
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 .

This could very well break a bunch of other stuff, but we'll see, it has my TiddlySpace dev environment working again.

Syndicated 2012-07-28 18:23:41 (Updated 2012-07-28 20:53:47) from cdent

sidebar

$(document).ready(function() {
var wholething = $('#text-html.section');
if (wholething.length == 0) return;

        var bag_name = 'theinformation_public';
        var host = 'http://theinformation.tiddlyspace.com/';
        $('')
            .appendTo('body');

    if (typeof(io) === 'undefined') {
        console.log('nosocket');
    }

    var socketuri = 'http://tiddlyspace.com:8081'
    , atdiv = $('#recents')
    var atbox = new Tiddlers(atdiv,
            socketuri,
            host + 'tiddlers?',
            ['recipe/' + bag_name],
            {sizer: 15});
    atbox.start();
});

Syndicated 2012-07-28 17:01:31 (Updated 2012-07-28 17:02:33) from cdent

The Usefulness of Useless Knowledge - Brain Pickings

Out of this useless activity there come discoveries which may well prove of infinitely more importance to the human mind and to the human spirit than the accomplishment of the useful ends for which the schools were founded.
The Usefulness of Useless Knowledge - Brain Pickings

This kind of serendipity is what I care about. Not the pursuit of solutions, but the pursuit of discovery.

Syndicated 2012-07-28 12:54:58 from cdent

491 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!