thingamy

thingamy manifesto

In these day of New Year Resolutions, Five Things You Do Not Know About Me and Hugh’s rapidly increasing list of Manifests I crumbled under pressure (thanks Hugh!).

Actually, manifesto? Well, more like a summary of reasons why we’re doing the thingamy:

1. The Organisational Hierarchy is kaput - as single purpose executor of the Business Model it requires reorganisation every time you need to get better, an utterly futile exercise most of the time. Replace it.

(Some more here, here, here and here.)

2. Managing is a waste of time. Leadership I need, getting out of bed in the morning I can do myself.

(More here, here, here, and here.)

3. Legacy software models the "way we always did things" - usually a model from the days of paper, quills and desks. Model reality instead.

(More here, here, here, here and here.)

4. Tree-structures are faulty. "Where it resides" is only two dimensional and suitable only for places. Use tags and any other means to enhance the knowledge and make finding easier.

(More  here, here, here and here.)

5. A report is simply logic applied to raw data. Apply when needed and keep all data in raw form. That will do away with applications, middleware, complexity and deliver far better reports.

(More here, here, here and here.)

6. Accounting was “invented” in 1573 1494 using paper and quills, dump it and let the IT system that delivers the flows capture the real data and display it any way you want real-time.

(More here.)

7. Budgets are completely silly. You know nothing about the future so forget it and leave such to soothsayers and magicians.

(More here.)

8. Think of processes as "what happens to things", not "what things happen".

(More here and here.)

9. Documents and forms are bad - they only document "what things happen" creating reconciliation, errors and rigid processes. Let the thing itself capture what happens to it.

(More here.)

10. Process is not a track, it's a football game where you see the goal and look for and try openings all the time. The ball is the flow.

(More here, here and here.)

11. Flow is everything - flow is relationship, flow is knowledge, flow is context and flow creates value. Your business is all about flows, never forget it. Build the flows, then better the flows to better the value and your margins. Do it, then do it again, then do it more. Think extreme Business Planning.

(More here, here, here, here and here.)

Here's an earlier twist to the issues if you care - You Know Something Is Wrong :)

documents, schmocuments and Pluto (more about thingamy)

I really dislike the terms "documents", "forms" and "files". And "planets".

Sources of missed opportunities. Instigators of late evenings at the office. The mothers of all bounced mails. The source of unimportant academic discussions with no end.

Is Pluto a planet?

Who cares unless you must categorise, position it, tree-structure it? But as pigeonholing is the preferred way... then we have to care.

Even for "information", stuff you cannot sit on, we still end up using the same method. We cheat and imagine information as "documents" or "forms", finite stand-alone objects, which makes tree-structuring / categorising / pigeonholing possible.

Thus your address have to be copied onto your Health Records, your Insurance Contract, your other... eh... forms. Then those copies have to be maintained and updated with great care.

Thus last month's sales figures will be constructed from the accounts (more or less, depending on efficiency of the post office), from a sales report, from a spreadsheet somebody did the other day, from  yet another spreadsheet somebody else did another day and from...

Hello end-of-month reconciliation headaches, hello mailing lists when moving. Hello never being quite sure everything is right in a dynamic world.

Multiple "data" objects pretending to represent one single real world object? That never worked, and it will never work.

Consequently "forms" and "documents" should be a thing of the (paper-based) past. Full stop.

That's why we do not use tree-structures in thingamy. Nor do we use "forms" or "documents".

We chop stuff and information up into smallest possible objects so no real world object need to be represented by more than one single data-object; one single address object that is "related" to your bank accounts, your employment contract, to... you. And to your spouse, your children, your dog, the property developer, the insurance company, the...

Then we use more than one method, in combination or alone, to describe such relationships ensuring that we can use the objects in meaningful ways later in any way possible:

Object built from objects: Very precise, very inflexible. A bike-object is built of precise numbers of unique objects like a frame, wheels, a handlebar...
Thingamy can build classes (the cookie cutter to stamp out unique objects) using any type of property and/or other objects.

Tags (use of multiple tags, otherwise it would be categorising): Very generic, can be used for anything, could be all-encompassing but for one reason - it requires some discipline to get precise results in a hurry. Thingamy has a tag-browsing bar (see image) that can be used in any interface, report or even in the midst of a task.

Links: Quite generic and very precise, but sometimes too structured. Perfect for iffy objects like persons. In fact a person does not even have to be an object - just a cloud of linked objects; address, medication objects, bank accounts, children...
And the links are bidirectional: Choose an address object and you'll find everyone living there, who lived there, who built it, the insurer, you know. Link or unlink objects at any time.

Containers: OK, granted that tree structures cannot be fully avoided, like for physical position of stuff when you need to pick it up: Box 43, row 14, room B, Warehouse East is an obvious one.

Who said tinkering with software should be boring?

:)

the fallacy of tree structures (chop'em down continued)

Apologies up front for chirping away, yet again, on one of my favourite themes - the stupidity of tree structures.

But as things goes, tree structures are too ubiquitous, and too faulty to be left alone. In my humble view.

Organisations, how they work, how efficient (or not) they are, how we organise and find stuff, how we build knowledge and other details of daily life. Tree structures.

And as long as that is the reality, I'll keep chirping.

Try this for fun:

Scoot over to your colleagues computer, ask him to describe a document he wrote two months ago.

You find the file on his hard disk. Time yourself.

Ask the next six year old you meet to describe a plant she knows.

Use the description to find it in the taxonomy of plants. Time yourself.

If you work in a big organisation, arm yourself with the organisational chart and access to the company web site.

Now find a colleague who is a good speaker, knows Python and speaks Greek. Time yourself.

Not very scientific, solely some indications that tree structures are less than perfect when used to find stuff, kind of the essence of organising stuff one would think.

Carl Linnaeus categorised plants by their number and arrangement of the reproductive organs. Hardly what comes natural to the above six year old when she wants to describe the dandelion at hand. Ditto for me.

And does the number and arrangement of reproductive organs render much useful "knowledge"? Well...

Did I mention the "knowledge" that is included in the title "Consultant Strategy & Change Business Consulting Services"? Does the fellow speak Italian?

Can I but conclude that tree structures are pretty useless when we want to find things and rather meagre on the knowledge bearer side?

Only thing they seem to be good at: Delivering rankings, be the power structure.

No good at the intended use, really great as a side effect supplier. Oh, great.

Chop'em down now.

finding, choosing, using (tags, not trees continued)

A black contraption comes into my sight, I quickly calculate the size of it, then recalculate a split second later to find that the image has increased in size. Then I add the facts that some round black and moving things are placed in all corners, round glass things in the middle, noise arising - volume increasing. 
First conclusion: I have headlights, wheels, motor running in front of me, ha, a car!
Second conclusion: Volume increasing, must be approaching, and that fast. Oops.
Final conclusion: Get the hell out of here!

Well, probably not. With the feeble calculating MIPS of my brain-cells I would've been roadkill.

My brain is far better at recognising patterns, immensely so. A few clues, probably merely the increasing sound volume of an engine would tip me off and make me jump even "before thinking". And good is that.

"Umbrella, children, film" - enough clues to give most an image of the film "Mary Poppins". Hardly what a programmer would have used as logic for a film recognition application. Absolutely not the analytical computational method.
Recognising an emerging pattern representing an object from a few clues...

A movement, a smile, a few words from an otherwise unknown person and you choose him to be your partner in the canyon transversing exercise on that company training camp. And usually it works out fine.
Recognition of a known pattern featured by such sought after objects...

At work, in the usual structured setting of structured organisational information structures we use the tree structures of manuals, catalogues and hierarchies when we are to find, choose and use a resource. Something that requires real training and knowledge. And a manual.
Otherwise you'll get lost at the second branch choice and end up with a goat as canyon-transversing-partner.

A tree structure is information structured at source, requiring a structured, logical, one-step-at-a-time method to find, choose and use resources. A path-to-the-object, not a pattern representing an object.

Perfect for computational and paper-based information repositories.

No good for humans.

We.are.the.best.at.pattern.recognition. Let's use that.

What we need is:

1. A system where the "characteristics" or "features" of an "object" or "subject" are independent of standards and structure.
2. Where all these "features" are presented and can be chosen.
3. That any combination choice of features is enabled for "pattern building".
4. With any set of features chosen (pattern) all objects corresponding to such "features patterns" shows for a quick and simple pattern recognition by a human user.

[Note: An early practical example of the method can be found here. Multiple tags ("features") choices as "stencils" to find patterns in an unstructured information repository.]

If I were to choose the canyon-transversing-partner from all company employees (say IBM... 234.000 employees) I think I would quickly tick off "nimble", "strong", "no vertigo", "English speaking" - and end up with 13.467 choices. OK, add "available" and I have 578. Being male and we're having fun so why not tick off "female" and... then ending up with 7 that I could zoom in on as in shaking hands with. You get the drift, I would probably end up with a pretty cool partner for the outing :)

Why not use the same method when choosing members to a project group? Instead of the typical set of "departments" and "titles" that we all know does not tell much.

Or for parts, suppliers, advisors... any resource?

["right", "rear", "estate", "light", "red", "audi A6", "2003", "April"] instead of ["XP87-pfGT-0009"]. No training required, quicker, no manual, probably more accurate as "pf" could easily become "pF" while "red" is not easily mistaken as "blue"! And of course more flexible in the case one starts making "white" and "orange" rear lights as well.

Easier, simpler and above all - a better chance of getting the best resource at the right time.

And that, ladies and gentlemen, is what business is all about, best use of resources.
Equal to more value added, margins increased, net profits exploding and general financial bliss.

Increase profits, make life easier, beat your competition, save resources - dump any notion of the need to structure the information at source, rely on patterns when choosing from the unstructured mess instead.

I'm still alive and bouncing after many years of traversing roads, purely relying on precisely that method. QED.

[P.s. Been a bit absent, much going on, a bit too much, do see end of tunnel, etc....]

accessible knowledge (tags, not trees continued)

Comprehensive, faster, and better delivery of knowledge by anataxonomy?

Hmm...:

"Knowledge is an appreciation of the possession of interconnected details which, in isolation, are of lesser value."

add that;

"Knowledge is distinct from simple information."

(From the good people at wikipedia)

Replacing the limited "trunk and branch" or "path" identifiers of a tree-structural organising method, anataxonomy's namespace imparts a comprehensive set of relationships for the object/subject:

When I tag an object or a subject I impart some of my knowledge, right or wrong, useful or not, does not matter. The moment another person with a different view adds his tags, the knowledge about the object/subject as communicated by its namespace will increase. Third one... and so forth, never ending story.

Two requirements:

1. The tagger must disclose him/herself and significant information about the tagger must be freely available. If possible, reason for why the tag was added should be added. This would then amount to what's known as "history source analysis".
2. No filter, standards or other form of single sets of logic may be used to limit tags. What the next chap feels is wrong, I may think is right. Two sides in a war will write two different history books - filter out one and knowledge loses out.

Anataxonomy - efficient organiser of objects and subjects, direct delivery of comprehensive knowledge and a true identifier - all in one swat - and all better than existing and separate methods?

Just a suggestion over the morning coffee... :)

[P.S. Aristotle pipes in with some support: "His ten classifications of individual words, the Categories of Aristotle - substance, quantity, quality, relation, place, time, situation, condition, action, passion - the questions we would ask in gaining knowledge of an object." Quite specific, even in sequence, but nevertheless tags...]

logical discussion (tags, not trees continued)

A few weeks ago I had a tag-discussion with a very smart chap who's work I respect a lot:

He suggested that filtering should be used to minimise the number of irrelevant tags that will appear if an object/subject is open to tagging by all.
Applying logic to the namespace-creation as it were.

He argued that if "Britney Spears" namespace consisted of a long row of "relevant" tags and somebody adds "nano technology", then that would be silly and should be filtered out.

OK, sounds reasonable... filtering, standards...

But, hang on, say a kid in Brixton started a rumour that Ms Spears had some sort of nano technology implanted in her left breast. Daft of course (and apologies to Ms Spears for the absurd idea), but still, it would not take long before a group in Brixton would use "breast" and "nano technology" as their first tags if they were to find the object of this fine lady.

And, the extra tags will not affect the namespace usability when in anataxonomy finding mode. It would merely broaden the group of users-that-can-find-the-object and perhaps even heighten the knowledge that can be gleaned from the namespace!

The grudge I hold towards tree-structures is the logic-applied-at-source and the ensuing:

• I have to assimilate the logic of the creator (wonder where this web designer placed employees in his navigation tree...)
• I need a manual (PKZ-8763-vy-55? What car part would that be I wonder, looking over the shoulder of my friendly Audi repair shop mechanic...)
• I need training (elevating the confusing to "intuitive", but effectively leaving out my not-so-young mother who's quite new to computing...)

With anataxonomy-in-practice we would have none of that, so why apply any kind of logic to free-tagging? Then the whole replace-tree-structure-exercise would be for the birds...

Let's not.

Let's have logic-free anataxonomy and bye-bye to training, manuals and loosing our ways :)

drifting away from the trees (tags, not trees continued)

David Weinberger here extracts this point from a post by Tom Coates here:

"Some use tags as folders to house objects, others use them as descriptions of objects."

Well put, and I would venture to add "tags as groups", as in the object being a member of a group.

Still semantics, dependent on where you come from, where your head's at that precise moment.

But all good and useful angles I would add.

[NOTE: My following points are dependent on the use of multiple-tags-interception method / anataxonomy-in-practice (pls use Firefox/Safari) along the lines of this example to find an object / subject.]

Tag as description:

• Adds meaningful knowledge to the namespace, in particular if we had some information about who tagged, when it was tagged and why the tag was chosen (source analysis in history comes to mind).
• Pro: Can be rather precise.
• Con: Too precise and may require assimilating logic of tagger.

Tag as membership to a group:

• Close to "tags as description", following the classic human attitude of "Show me your friends and I'll tell you who you are" kind of approach. Useful, but I would have to keep those tags quite dynamic, first impressions having a tendency to be wrong :)
• Pro: Almost like a metatag, gives lots of information in one go. Imprecise, requires less logic assimilation.
• Con: Very wide, very metataggish and have thus to be quite dynamic as view of object/subject changes over time.

Tag as position:

• Useful to describe physical whereabouts of course, easy to fall back to when in a tree-structure-mode.
• Pro: Good starting point when moving from tree-structure, porting my 593,406 files from tree-structure to tag based structure could be by tagging purely with folders, including sequence of course. Then add meaningful tags as time passes.
• Con: It's after all tree-structural and sequence matters thus assimilating tagger-logic is required!

In summary:

It does not matter where we start as long as we let the process flow towards what is natural, whatever that would be (you know where I stand, but this works even if I'm wrong - cool eh?).

No extra and precise tag will ruin for the other tags. No imprecise tag is useless unless on its own. Even tree-structural tags can be useful as it tells a story of times past :)

Add the paradox raised by Tom that a hundred year old subject/object where "obvious" tags would change over time: Using the "anataxonomy in practice" the new or old tags would not matter, modern man would use the current cloud while the ultra-conservative would use the old set - and none would ruin for the other!

Example: Take a HR system using tags only to "organise" people, start with a virtual hierarchy with departments and positions as tags - and the current managers will find the person. Then add tags to add knowledge about the people, factual descriptions (speaks fluent Italian), subjective impressions (grumpy in the morning - tagged by subordinate, friendly in the morning - tagged by boss ;)

Add more tags - at some point the hierarchical tags does not matter any more. That would make the transfer from hierarchy to tag based structure rather painless!

Knowledge of the person would move from the "heard in the cafeteria" or "fifth paragraph, second page on a CV in some drawer" to a common space adding transparency, better use of resources and dynamic increase in namespace-value.

:)

boolean conversation (tags, not trees continued)

"To OR or AND, that's the question."

Some very smart chaps have their say on the matter:

Valdis says: "It is an AND situation... hierarchy AND network"

Craig says: "In other words we need hierarchical structures AND network structures to move forward."

Doc suggests diplomatically and with my favourite metaphor of the month (!): "That makes it a tree of a very short sort, perhaps the height of moss."
I'll read that as a cautious support for the OR camp :)

Now, in contrast to pure tree-structured organising systems like file systems, data bases, etc. - a (organisational) hierarchy has two tasks:

1. Organise data (resources, transaction data, information, objects etc.) so they are easily found when needed.
2. Structure and direct the process flows.

Keep those task apart and I think the discussion will be easier.

Obviously, anataxonomy and our little practical example (pls use Firefox/Safari) will only be able to handle the data organising. But I would notch up an OR for this "half" of the hierarchy purpose.

Structuring the process flow is a different story as no real practical alternative for this task exist.
So it would be an AND today, hierarchy AND network structures (or whatever) supporting the views of Craig and Valdis.

But find an alternative method to organise the process flow, then the hierarchy could be superfluous. And OR being the choice.

Funny thing, this is precisely what we're working on, the (main) Thingamy system should be able to deliver the process flow structure. With the anataxonomy method for data organising built in, then both task should be covered by one system (but with two methods).

Then I may be able to say hierarchy OR something else!

More interesting experiments to come, watch this space for such (but after a few weeks of summer slowness I'm afraid :)

tags, not trees

Take my new tree-structure-free gizmo (pls use Firefox/Safari) out for a test drive:

What is it?

Whatever you want it to be: Navigation-free website. Tags-only blog. Complicated-to-simple database. Active resource picker. Knowledge and learning base. File system. Whatever. An experiment for the heck of it.

Basically a different approach to organise data, finding data, and transferring knowledge.

An example of no-tree-structure-at-all. Anataxonomy in practice:

• Organising:
  Free, dynamic and imprecise tagging of objects/subjects vs. fixed positioning in two-dimensional tree structure.
• Finding / Identity:
  Intersection/overlapping of multiple imprecise tags with no regard to sequence nor logic vs. precise navigation following learned standards / unique logical positions.
• Knowledge:
  Object/subject relationships directly visible in identity vs. identity plus large amounts of data linkage.

Enough talk, here's the tagwork, but first a few hints to ease you into it:

(Please, please use Firefox or Safari... anything but the "that browser which cannot be named", otherwise some features (modern technology and such) does not display nicely.)

1. Write "wa" in the field.
2. Click on "War", then "Wall" - see what happens.
3. Write "sm" in field instead.
4. Click "Smile".
5. Unclick "War".
6. Got it?
7. Click on any object-link and see whole text body, add comment (including more tags to comment) or add yet more tags to object/subject.
8. If you need to create a new tag use "Add tag" on top of tag list.
9. Please add another "art object" by hitting "Add object" on top of tag list and tag it at will!

[Note: The "art data base" is not the world's largest with its 15 objects (OK, I'm lazy, and no DB import function yet :), so feel free to add more objects. Anything is appreciated, it's only a test man!]

Now go there: http://thingamy.com/tagwork/ - enjoy! (pls use Firefox/Safari)

P.s.
The "tagwork" is a hands-on experiment, its traits are intrinsic to the Thingamy run-the-business system as base for the system's built-in communication (CMS, blog, mail-client etc.) and any interface where resources/data/objects/subjects have to be organised and found (HR, production, accounting, reports, etc), and choices have to be made (in process, workflow, etc.).

That said, the example have a nice admin back-end and can stand alone as a CMS, data repository, file system replacement (heh, why not?), blog system (let's add RSS and trackback), different take on wikis or whatever you could imagine.

tree-structures, are we hardwired?

If I say "Book" and "42", what comes to your mind? Some "Hitchhiking" perhaps?

What with "Umbrella" and "Film"? Any film titles coming to mind?

Add "Nanny", "Flying"... would that be "Mary Poppins"?

See? Your brain is quick and naturally wired to intercept iffy tags!

Nevertheless, I often hear that tree-structures are necessary and that we are hard-wired for tree-structure organising: Hierarchies, folders...

That I would argue, humbly of course, is bogus.

Would "Film > British location > Female lead > Disney > Family > etc." trigger "Mary Poppins!" as promptly?
Nah, didn't think so...

We're naturally inclined to tag imprecisely and freely - and locate any object or subject intercepting those tags. Fast, efficient and without training. And without any quest for standards.

In other words, we need no classic tree structured data sorting. We would be better off without.

And with that goes most of the reason for hierarchies. And with hierarchies goes the command and control nodes named management.
And then departments, and thus marketing as we know it.
And titles.
And how we build knowledge. And how we learn.

And why not rethink, remake and replace the whole shebang? All of the above.

Yeah, why not? It's only Sunday, enough time to make the world a better place by the end of year :)