Hate driven development

I hate writing tests. I hate not having tests even more. Therefore I write tests. Hate begets hate.

The Hygiene/Product/Relation model fo...

This is a little something I wrote a year ago to clarify my thoughts on the future of telcos. It's still in a draft format, but it also may still be useful so I'm publishing it. sept 30 - 2010 - rmz

DRAFT



A Hygiene/Product/Relationship model

for communication products.

by



Bjørn Remseth

October 2009

The basic idea

Communication products satisfy needs may conveniently be grouped into three groups: Hygiene, Product, and Relationship. The hygiene needs contains features fulfilling that absolutely positively needs to be in order for anyone to bother using a product. Product features are whatever is necessary to work with products: Names, brands, pricing, product identifiers etc. Relationships are the reason why communication takes place in the first place: They motivate the need for communication.

Motivation and inspiration

The model is inspired by Maslow and Hertzberg's work.

Maslow's studied successful people:

Maslow based his model on studies of successful people (Einstein being one of them), so in a sense he worked "top down" to make some sort of sense of how successful people (self-realizers) behaved. In brief, what he found was

Maslow saw human beings' needs arranged like a ladder. The most basic
needs, at the bottom, were physical—air, water, food, sleep. Then came
safety needs—security, stability—followed by psychological, or social
needs—for belonging, love, acceptance. Then, came esteem needs—to feel
achievement, status, responsibility, and reputation. At the top of it
all were the self-actualizing needs—the need to fulfill oneself, to
become all that one is capable of becoming.

(source http://en.wikipedia.org/wiki/Abraham_Maslow)

This is a useful model, since it means that all needs are not created equal. If you have no air, nothing is more important than air, but if you have enough air, even more air is not really of any concern. In my mind Maslow's layering ties in to the concept of diminishing returns but relates it to human motivation rather than economics. I find this important since motivation and tastes are highly important for human behavior, but economics says nothing about them.

Herzberg studied what motivated engineers and accounants at work:

Herzberg interviewed a couple of hundred accountants and engineers in the Pittsburg area to try figuring out what motivated them for work. His findings are summarized (very briefly :-) in Wikipedia:

Two-factor theory distinguishes between:

• Motivators
  (e.g. challenging work, recognition, responsibility) which give
  positive satisfaction, arising from intrinsic conditions of the job
  itself, such as recognition, achievement, or personal growth^[4], and

• Hygiene factors (e.g. status, job security, salary
  and fringe benefits) which do not give positive satisfaction, although
  dissatisfaction results from their absence. These are extrinsic to the
  work itself, and include aspects such as company policies, supervisory
  practices, or wages/salary^[4].
• (Source: http://en.wikipedia.org/wiki/Two-factor_theory)

That is the basic idea: Hygiene factors are those needs to be fulfilled otherwise you'll be irritated, motivators are what will keep you there even if you only have a slight chance of achieving those needs.

Both Maslow's and Herzberg's models are nice constructions for human behavior in general, or at least for the generally successful people Maslow studied and the engineers and accountants in the Pittsburgh area Herzberg interviewed. But how can I apply them to understanding communication products in a business setting? Actually it turns out not to be so hard :-)

A three layer model of communications products

Product features seen as a set of Hygiene/Product/Relationship features.

I propose a model to describe communications products. The lowest level are the hygiene factors, the needs that has to be adequately addressed before anyone will even think about using the product on a regular basis. For speech telephony such factors will be sufficient basic geographic coverage, legal use of the service (as opposed to e.g. illegal radio telephony), adaquate voice quality, sufficient availability. Initially all of these factors will be basis for competition between companies, but as the industry matures it is to be expected that everyone who survives the competition will be adequate in these areas. It is probably fair to say that in a mature market all competitors have hygiene factors down cold, if not they wouldn't be competing. Over time exactly what constitutes a hygiene factor will probably change somewhat. Data communications and web browsing capabilities wasn't a hygiene factor when cellular phones were introduced, but it is arguably becoming one now.

That takes us up one level to the differentiators. Products have a set of product-specific parameters: Phone numbers, customer identities, price plans, payment options, credit management, customer service, brands targeted at and communicating more efficiently against various segments etc. There is a whole industry built on tuning product parameters and pushing products using various different combinations of interesting graphics, beautiful people and catchy music. And of course pricing the products in ways that are competitive when compared with what the competitors come up with. Gaming product parameters is a fascinating endevour that can and do occupy several lifetimes worth of activity in major corporations. However, it is a mistake to believe that customers are primarily interested in products or tightly product-related features.

Nobody is so interested in talking that they will regularly pick up a phone and start talking in it regardless if there is anyone in the other end of the conversation. Everyone I know who talks in the phone talks to someone for some reason. There is a wide range of needs that can be fulfilled by talking to someone, but I choose to group all of these reasons into one category: Managing relationships, and that is why I call the top level in the model the "Relationship layer".

There are many relationships to be managed: Friends, family, colleagues, interest groups for this that and the other thing. At various times these needs to be (among other things) understood, coordinated, managed, convinced, impressed, seduced, coerced and bullied. All these needs are usually independent of any particular product that is used to fulfill the need. The product is a means to an end, not the other way round. But this doesn't mean that the product has no business in helping the customer to manage their relationships.

How is this model useful?

Perspective

The immediate usefulness comes from the perspective it takes: It puts the users of the communication services (in our language, "the customer") and their needs at the top. Furthermore it imposes an ordering of the needs. Some needs are "hygienic", irritants if not met but otherwise not something one notices. Others are "motivators", and direct user behavior once hygienic needs are fulfilled. Product parameters are somewhere in the middle: To some extent they are hygienic, you don't want to think too much about it but become irritated when they are missing: Voice quality, coverage, correct invoices and customer service that actually offers service all fall into this category.

For the most part however, the relationships that are the subject matter of and motivator for almost every phone conversation is seldom explicitly assisted by the actual communications product, at least not for private commercial voice communication products. Business subscriptions and switchboard services are arguably in the relationship management part of the spectrum, but for private customers and private subscriptions it is harder to find any part of a phone subscription that facilitates relationship management. The only thing I can think of are ring-plans that makes it somewhat less expensive to call your family and closest friends.

This leads us to the other actors: Handset manufacturers are very much into the relationship management business. They have understood that managing conversations, phone books, images, groups of people in the phone book etc. is important for their customers. They understand that ringtones that indicate who is calling, and selective blocking of incoming calls is useful for the customers. It is unclear to me if the handset manufacturers actually understand that what they are doing is relationship management, or if they are simply seeing themselves as managers of a bunch of product features that happen to be possible to embed in a handset. I guess both interpretations are possible, so they are probably both true. The fact remains; handsets are tools for managing relationships more then they are tools for managing phone subscribtions.

Some of the new voice actors, in particular Google Voice and Ribbit (and to some extent Skype) are very much into relationship management, and I do believe they know what they are doing. Google Voice handles call screening, like many handset does, but also makes it possible to route incoming calls to various different voice mailboxes, and offers a speech-to-text service that lets the user or computer programs acting on the user's behalf react to incoming messages. Ribbit's first commercial product (as far as I know) was focused on assisting salespeople by facilitating their relationships with their customers.

The components that facilitate relationship management seems to be more compute-intense and less network oriented than voice. This may be somewhat misleading since compute-intense tasks may very well also be network-intense, but that is invisible to the end user who may only perceive voice communications as network-intense. At least that is how I think about users thinking about this :-) Nonetheless, I believe it is fair to say that relationship management is either more compute intensive than voice transmission, or uses a broader range of handset capabilities than pure voice, or both. This means that if relationship management is important for successful future speech products, then telecommunications companies must either leave the stage altogether and leave relationship management to others, or they must increase their presence in relationship-related products.

---

Extendability to other communications products

So far I have only discussed voice communications, but the hygiene/product/relationship perspective can be applied to other classes of services as well. Here is a short sampling of other types of products and their decomposition into H/P/R components.

	Google Mail	Picasa web album	Flickr
Relationship	Conversations, filtering, autoreply,	Sharing, visibility, groups	Sharing, visibility, groups
Product	Freemium, Outsourcing of mail for organizations	Freemium, google account	Freemium, yahoo account
Hygiene	Send/receive mail, enough storage to not bother about quotas, high availability, chat integration, Google ID	Storage, image manipulation, geotagging, tagging, freemium, use Google ID, screensaver, printing, infusing content into social networks, ratings ...	Storage, freemium, tagging, commenting, feeds, searching, use Yahoo ID, screensaver, printing, spreading into social networks, ratings, ...

An important thing is that these products explicitly care about relationship management. They are not afterthoughts, it is really important both that conversations in gmail are threaded correctly, and that comments and ratings in Flickr are well executed. They are not tacked on to "have ratings", they are central for the product's sucess, since they enhance the relationships of their customers.

Identity

Identity is who we are. It is not a term that is easy to pin down. Being a parent is part of some people's identity, so is their email account, but those two aspects of identity are very different and other aspects of identity are different from these two still. Wikipedia defines many different meanings of identity, here is a sampling from the social sciences section of the wikipedia article, all of which are relevant when thinking about the kinds of identities that goes into relationships that motivate communications:

• Identity (philosophy), also called sameness, is whatever makes an entity definable and recognizable
• Identity (social science), umbrella term used to describe an individual's comprehension of him or herself as a discrete, separate entity
• Cultural identity, person's self-affiliation (or categorization by others) as a member of a cultural group
• Gender identity, also known as core gender identity, the gender(s) or lack thereof, that a person self-identifies with oneself
• Identity formation, the process of the development of the distinct personality of an individual
• Identity politics, refers to political arguments that focus upon the self interest and perspectives of self-identified social interest groups or minorities

(source http://en.wikipedia.org/wiki/Identity)

The wikipedia article then lists other types of identities that are in fact also relevant for communications services. For the sake of this discussion I will choose to concentrate on the philosophical definition above, "whatever makes an entity definable and recognizable".

From this definition, we see that the H/P/R layers have different aspects of identity. At the lowest layers are technical identifiers that are necessary for communicating. For phone networks these include MSISDN numbers, and for Internet services they include domain names (DNS registred names) and numerical ip addresses. These identities are necessary for communication to take place, but they are by and large (with some exceptions for DNS) not related uniquely to neither products nor customer's relationships. Product identifiers include email addresses, phone numbers, URLs to websites, product names, product numbers etc. OK, I'll admit it, there are meaningful relationships in the product layer: Product/customer relationships exist and they can carry importance. However, at the relationship layer people expose their identities: Their affiliations, the processes that form them as individuals, the social interest groups the take part in or sympathize with. All of these things are up there in the relationship layer, and may or may not be closely affiliated with the identities at the lower layers. They certainly don't in general depend on lower layer identities. It is fully possible to love cats without having a Facebook identity, but it's so much easier to join up with and relate to other people interested in cat welfare if you do.

And that's where the the thesis of this little piece becomes clear: Anyone who wishes to play a role in the relationships that exists between people had better be relevant at the venues where relationships meet product identities. If you wish to communicate with people interested in cat welfare within Facebook, you will send them an email or send a message to the group. You won't call them because Facebook does not currently offer voice telephony. But what if Facebook did offer voice telephony? If you had the option to "click to call" anyone on the group, or perhaps to have a "party line" conversation using voice telephony, who is to say it wouldn't have been used? But it isn't used, because Facebook isn't offering any form of voice telephony.

My point here is that any service provider who has positioned itself at a junction where relationships and technical identities are matched is ideally placed for selling technical products that facilitates relationship development. Those that don't position themselves at this junction will sooner or later be bypassed by those who do when they by some means gain access to voice telephony.

At this point I should note that the technical infrastructure necessary to offer voice telephony is really quite well developed. The main obstacles are a combination of technical, pricing and regulatory, but that is the topic for another time.

---

What should be done by incumbent voice actors?

A witty saying proves nothing

Voltaire.

Wait and see
The simplest thing to do is just to wait and see. I make a few predictions above, in particular I predicted that at some point barriers for entry into regulated voice telephony for internet actors will be lowered. At that point the internet actors will play hard on their mastery over relationship facilitation and pure voice actors that chose to "wait and see" will have a number of very bad days at the stock exchange. Until barriers drop not much will happen. Place your bets.

Do some research

• What motivates users? Talk to users, interview them. Find out what motivates their use of communications products, see if those motivations fit with the model depicted above or if some other system is better at describing their needs.
• What are the regulatory changes on the radar? What we want to know is how regulatory barriers of entry for internet actors into regulated voice will be affected by regulatory changes that are planned or being talked about. Find out which changes are in the pipelines in the relevant jurisdictions, which will include the US and EU regardless of which market you are interested in. Who supports and opposes them, what is the timeframe for their implementation, and what can their impact be?
• Long Term Evolution: LTE. What is known about the technical capabilities of LTE (and competing future technologies) and future voice over IP. What is know about the introduction of LTE in relevant markets? What are possible timeframes for Voip over LTE to be realistic opportunities for internet-based companies to gain "first class" access to handsets?
• Consider pricing of data traffic: Perhaps it's ok to lose some or all income from dedicated voice services? Perhaps it is better to increase the price of data traffic to a level where income from that is sustainable as a source of income for wireless operators? This will mean that speech will be just another type of service over a generic networking device. Perhaps that is a reasonable future? I don't know.
• Roadmap: Make a reasonable roadmap for voice for the next ten to fifteen years. Plot in the technological and regulatory milestones and estimates/guesstimates for when they will be passed.

Get serious about relationships
Another thing that can be done is to start playing the relationship game ourselves. This is harder than just to wait and see since it involves actually trying to make better products for our consumers, not just to print nicer logos or tweak price plans. Helping subscribers to manage their phonebooks, which is the entry point to many of their relations, is an obvious move. Another move is to make voice relevant in internet-style relationship-managing services: Invade Facebook, Google, and Microsoft's universe and make it easy to use regulated voice there. Make the phone-subscribtion/online identity (or identities) relationship (or relationships) matter. Vodafone goes a bit in this direction with their Vodafone 360 initiative, and theirs is an important step but there is certainly more that can be done. Facebook, LinkedIn, OpenSocial, MSN, Hotmail, .... . They are all opportunities for integration and product development, but for sure they are also threats.

Think about the brand

Telcos need to do some soul-searching: Who are we? What do we do? Are our customers' relationships of any interest to us? Is voice and radio networks our prime concern, not the costumer's needs? Whatever we choose, how do we express that through our brand? If relationships are to help us defending income from voice, then perhaps this should be reflected in our brand? If so, how? All I can say is that this sounds important to me, but since I know next to nothing about brand management I'll just raise the questions and offer my participation in any discussion about it. I won't even begin to try to offer any conclusions.

Further reading:

Voice Chat app Vivox comes to Facebook. http://news.cnet.com/8301-17939-10367465-2.html

Phone calling coming to twitter. http://news.cnet.com/8301-13772_3-10355319-52.html?tag=mncol;title

About google voice: http://www.google.com/googlevoice/about.html

About Ribbit: http://www.ribbit.com/

Wholesale Applications Community (WAC)

Ok. It's time I blog a bit on this:

What it is?

WAC is essentially a bunch of telcos banding together to make "their own" ecosystem with appstores, trusted certificates etc for applications based on javascript with access to various phone and network assets meaning that these javascript apps can query the phone about where it is, set up phone calls etc. The javascript part of WAC will be adopted from W3C's Bondi initiative, the rest will come from somewhere else and I'm not at all certain of the details about how this will come about. Perhaps someone knows, but for the sake of the argument I'll assume that this will be sorted out in some reasonable manner.

Why WAC may be a good idea?

It's the Web, stupid.

In short, because it's the web: This will let the web get a first-class-citizen position on the handsets: Just like web applications on the web today in principle can do just about anything a native app can, wac will enable web apps to do a lot of things that have up to now been firmly in the bailiwick of native applications; like calling, contact list management, taking pictures, sending and receiving messages etc. All of this is good. It means that the tentacles of the clouded web will be able to infiltrate the handset as if it was just another web connected device, which it will now be.

It will annoy Steve Jobs.

Now in the spirit of full disclosure, I'm an admirer of Steve Jobs but there are many things Apple does that annoys me. One of those things is the way in which they lock developers into a very narrow straightjacket of terms, conditions and development environments in which they must work. It's not allowed to write code for the iPhone in anything except C++, Objective C and C, basically. That's .... barbaric. However, it does make sense for Apple since it greatly reduces the degrees of freedom that they have to manage in order to maintain a polished and sanitized environment for the iPhone. There is only one little chink in Apples armor, and that is ... the web. The Safari browser runs javascript. Javascript is the only unsanitized language allowed on the iphone. It is excactly this weakness WAC (or more precisely Bondi) attacks. This means that at some point Apple will be faced with a choice: Either they neuter their Javascript engine by excluding the Bondi extensions (and that will be hard when Bondi is an official part of W3Cs recommendations for how Javascript engines should behave), or they allow Bondi in on their phones thereby opening them up for an entirely new ecosystem of unsanitized apps that can tickle all the parts of the iphone that can presently only be accessed by developers that has signed Apples rules and regulations for appropriate behavior. I'm sure that if Steve is still alive if or when Bondi becomes a W3C standard, there will be one or more Steve jobs moments where he explains whatever path Apple chooses.

Now, this may sound as if Wac is a bad thing for Apple, but in reality it isn't. Apple has played its cards extremely well. When the iPhone came out it was at least two years ahead of all competitors, and it hasn't been standing still since. This ment that Apple basically had the iPhone segment of the market all to themselves, and any terms whatsoever that they dictated had to be acceptable because there were very few alternatives. Basically Apple had created themselves a temporary monopoly by virtue of being exceptionally innovative, so naturally they exploited this monopoly by extracting monopoly profits, and their terms and conditions are just a means to an end for this objective. Now if you look under the hood of the iPhone there is actually not that much that is very special there, this if anything makes the fact that it is so innovative more impressive btw. : Under the hood there is the Mach message passing kernel. On top of that runs a BSD based Unix directly derived from the desktop OSX which in turn is a direct derivative of NeXT's operating system, with some influence from the FreeBSD project. The window system is based on OpenGL on top of which a modern-looking version of NeXTs old GUI code is run. The strength of the innovation is not so much in the basic technologies used, most of them are actually more than ten years old, but in the flawless execution when putting all of this on a handheld platform while keeping power consumption down and adding perhaps the best industrial design on the planet to the physical design. However, from the list above it should be obvious that there is very little of the technology in the iPhone that requires a closed environment to thrive. In fact, all of the software components (including the GUI) has open source equivalents that are either identical or just a hair worse than their Apple counterparts. This means that Apple has a looong way it can slide in the direction of openness without breaking any fundamentals of the iPhone's success. It will perhaps mean that they will cash a bit less monopoly profits, but that is only to be expected: After all, nobody expect Apple to remain alone at the head of the field forever. So, my conclusion is that Apple has a lot of defensive depth: They can allow Bondi to access the phones, they can allow interpreted languages on the iPhone and they can do it without breaking their success, but even more important: They can open up when they choose on terms of their choosing, and they can do this because they chose their starting position very intelligently. My hat off for Mr. Jobs :-)

It will enable first-class communications clients on the web

I'm not sure if the telcos have clued into this, but WAC will actually weaken their monopolies: After all, javascript is already present in all kinds of browsers on the desktop; what is there to stop them from implementing the Bondi APIs, hooking those up to some backend (e.g. voip) and voila: Universal communication clients that are wholly independent of telco infrastructure. Or more precisely, communication clients that can opportunistically choose what type of infrastructure they wish to use, and that process of selection will be mediated through the web, not through the signalling systems of the Telcos. This is good news for customers and web developers, and for developers of modern telephony, but not necessarily so good for the old monopoly-based telcos ;)

If it takes of at all is not dependent on telco support in the long run :-)

This may sound a bit weird since it is the telcos that are pushing WAC implementation, but if you look at my first point "It's the Web stupid", it becomes obvious: Wac will let the web infiltrate the handsets. This will of course happen quicker if the telcos are onboard and actively helping, but once it is done the telcos are not that important. The appstore thingy may or may not become a success, but imho that is of little importance in the long run. In fact, it may well be that telcos will ultimately meet stiffer competition from web-based telephony operators made possible by prevalence of the Bondi APIs

Why WAC may be a bad idea?

It's the stupid telcos!

Buy and large the Telcos don't grok the Internet. This time it may be different, but it's always been that way and I'm not holding my breath this time. The telcos are banding together to promote their own interests, which tend to be: Their own (super) profits, (total) control over ("their") networks and lately also fierce competition with other telcos (meaning that they will fight by any means available to maintain market share, a lost customer is lost revenue and there is a finite supply of customers). I believe this creates an unstable situation for any cooperation: No software developer in their right mind would want to put their future in the hands of the telcos.

If the telcos are to create some common infrastructure for say a marketplace for WAC applications, they would have to both be attractive to developers, compete with all other marketplaces in the world, but at the same time they will have strong incentives against destroying their own profits by say, allowing universal communication applications to develop.

Also they will have incentives to defect from the cooperation. Consider this scenario: Some handset manufacturer sees the WAC marketplace as a threat, so their defensive move is to allow Bondi-based applications into their appstore, but they won't allow applications from the telcos WAC-store to be installed in their handsets (for security reason, naturally). Developers will simply say "ok, we'll just submit the app one more place, no big hassle". Now the handset manufacturer can approach the operators and say: "You know, this whole WAC thing is bad for security, so if you defect from the WAC consortium we'll offer you our latest and greatest handset ahead of your main competitor, and your customer's won't be harmed by this since all the best WAC applications are available from our appstore anyway, what do you say? If you say no I'll naturally talk to your competitor to hear what they say, and by the way the xPhone-8 will be a really great product, to bad if your customers have to wait eight months before they can get some".

Conclusion

In short, I believe that the telcos' vision of what WAC will mean for them is mostly mistaken. It will in all likelyhood not become a viable alternative to the appstores that is already established. Bondi enabled web-applications both on and off handsets will be to the benefit to both developers and end-users.

The only way in which telcos can actually gain from WAC is to grow a clue, and learn a lot, and to do so really fast when reactions from real developers and real users on their perceptions on what WAC means starts to come in. My guesses on what they should learn is:

1. The Internet is here to stay. Deal with it.
2. Helping people to leverage their relationships is at the core of the telcos' business. More so than making sure electromagnetic signals flows through various media (fiber, air, copper).
3. Since value is created by connecting people to people, and people to services, making this process easier for everyone will enhance value creation.
4. Monopolies (natural or artificial) don't last forever, and are not necessarily part of the core business. By all means use monopoly power when you can get , but realize that greed isn't always conducive for your long term health.

... but I'm not holding my breath on this one either :-)

The age of mobile voip starts today (for me anyway)

Mobile VOIP. I don't remember exactly when I got my first phone with a SIP client, five years ago perhaps? However, in practice this didn't make any difference since it was useless: The phone application was buried deep inside some obscure menu, it was not possible to use it as the default call aplication (or even a convenient second) the wifi connection was mostly useless, it wasn't possible to use voip over the telephony network (this was pre 3G) etc.

However, today most of this changed. I tried out the new Bria iPhone edition voip app, and it was mostly brilliant: It works. It works over wifi an 3G. The voice quality is excellent. The call application looks very much like an ordinary call application. Bria can't replace the default caller application, but on the iPhone that doesn't matter very much due to the desktop-based navigation metaphor. The only gripe I have so far is that it doesn't seem to be possible to call into the phone through 3G even with the application started. I haven't discussed and debugged this with my friendly voip vendor, so it may be a configuration issue, we'll see.

The upshot of all this is, for me, that today july 6, 2010 the age of mobile voip starts. This means that after this date call routing through the mobile network is only one of several options for making practical mobile phone calls. I'll probaly elaborate on why and how this is very important news (the future growth of Google Voice and the inevitable delamination of carriers are two issues closely related to mobile voip), but not today :-)

Cryptographic accounting

The word "Cryptographic" comes from Cryptography (or cryptology; from Greek κρυπτός, kryptos, "hidden, secret"; and γράφω, gráphō, "I write", or -λογία, -logia, respectively. It basically means "ways of keeping written things secret".

I just invented the term "Cryptographic accounting". It means accounting that keeps things secret, sometimes intension, but sometimes just as a consequence of the way the accounting system is designed.

Cooked books

I know about two subtypes of cryptographic accounting. The first is the traditional "cooked books". The ledger that is modified to please the intended audience. I recently listened to an excellent podcast from LSE titled "Does Management matter?" by Professor Professor John Roberts from Stanford University where he talks about the textile industry around Mumbai. He reports that it is usual for these companies to keep three accounting books: One that they show the government for taxation purposes, another that they show to the bank to qualify for credit, and a third that they keep for themselves to know what's really going on. These practices

are well established but they are also clearly fraudulent and well known, so I won't say much more about them except to say that if you know how the books are cooked, you can get back to the real results, sometimes easily. In that sense this is a weak kind of cryptographic accounting, since it is in theory easy to find the secrets that are being hidden.

One Way Ledger

The second subtype is a bit more interesting since it makes use of a new invention that I call the "One way ledger". The one way ledger the characteristic that the numbers in it are alle true, no fraud anywhere, but if you try to use the numbers to find out anything of substance, it just won't work. A typical example is this: A company produces widgets and gadgets.

The ledger states how many widgets and gadgets are sold, and how much each was sold for, and consequently how much income was generated. However, the production cost is lumped togeter in a set of numbers called "production", "more production" and "even more production". Note that the identity of the products is lost when considering production costs. This means that while it is possible to know if the company itself is profitable, it is impossible to know if it is widges, gadgets or both that are contributing to the profit. The "one

way" aspect of this ledger means that you can read it from top to bottom, to figure out where the income is and where the expenses are, but you can't read it from bottom to top to figure out which product was actually contributing the most to profitability. The reason this

is a one way function is simply that two well established cryptographic mechanisms are employed: Diffusion and confusion (see wikipedia entries here and here, as well as Shannon's seminal article on the subject here) , The "diffusion" mechanism means that localized changes in the secret leads to changes in many locations in the encrypted document. For an one way

ledger this means that a change in the number of widgets produced affects many of the the production processes. The "confusion" part means that it should not be very obvious how changes in number of produced units affects production costs. Lumping more or less

unrelated costs together is a good way of doing this. One way to achieve this could be to lump "packaging" for all products into one number. After the costs have been summed for all products, it is impossible to find out which products contributed most to cost.

Untangling an one way ledger is really hard, even for organizations who wants to. The reason is that all reporting routines are made to fulfill the requirements for the official (one way) ledger, so it is rational for everyone in an organization to remove the information that is not in it (rational, since nobody will get any credit for reporting what isn't required by the reporting routines). This means that if you wish to find out what is going on, the reporting routines has to be changed, accounting systems has to be modified, auditors need to find ways to compare the new numbers with the old so the stockmarket won't be confused by the new accounting practice etc. This means that once established, there will be great institutional resistance to removing the one way ledger system. Consequently it will most likely stay in place until some external event (e.g. a competitor with better cost structure due to more appropriate accounting practices) disturbs the internal equilibrium between the organization units and gives incentives for reporting actually useful numbers.

Since it is really really hard to untangle ay established one way leger, this qualifies as a kind of "strong cryptographic accounting". It hides things really well.

Thrift under windows XP

Thrift is nice. It's a decent RPC framework, it's seems quite developer-friendly as long as all the right nuts and bolts are attached in their proper places. This includes having a compiler running on your development system.

For various historical reasons my primary development system is now based on Windows XP, but with daily contributions from OSX and Linux. This means that if I'm to use Thrift, I need a Thrift compiler on XP. This is why I have spent the better part of a day making that happen.

I'm still not certain if i've got everything right, or even if I've gotten enough right for my installation to be really useful, but I do have a running version of the thrift compiler and it seems to be compiling thrift code written by someone else on my project so I have good feeling about this.

Now: What did I have to do in order to get thrift up&running?

• First I took a peek at this page that explains some things that needs to be done. I tried the binaries, but they are useless and obsolete, so next I tried to compile things for myself. I chose the Cygwin option.
• First attempt failed badly, no malloc or free found in (lib/cpp/src/Thrift.cpp), so I added "#include " and that bug disappeared.
• Then I had to move my ant installation to somewhere without a space in its path (that wasn't so hard, I just made a junction (the windows version of hard links) from C:/ to the old installation and put the location in the path). Since paths are hardwired into the makefiles, I had to run ./configure to make this change valid.
• Then many and varied strange things happened. I didn't really catch on to what what was happening until I saw something along the lines of "FIND " (some error message). The clue here was the capitalized FIND. This indicated that it was windows's find-implementation, not cygwin's that was being used by the make scripts. So I had to change all instances of "find" to "/usr/local/find". I guess i could have changed my path instead, but I didn't. You might want to try to change the path before rewriting all the makefiles :-)
• Then tings compiled. The compilation stopped with some error message, I restarted it, the compilation continued and finally terminated successfully.
• I ran "make install" and got myself a thrift.exe installation in /usr/local/bin (cygwin path).

I won't claim that this will work for anyone else, or even to claim very strongly that it has worked for me yet, but this is what I did, and so far it seems to have produced an useful result.

The mind boggles at the fact that this is actually (probably) the simplest way to get a decent RPC mechanism compiled on windows XP in 2010.

The Innovation Antipattern

My good friend Bjørn Borud recently sent a message about somthing he calls the "Innovation antipattern". He may or may not blog about it himself, but I felt that the pattern was too good to remain hidden in one of our semi-internal mailing lists, so here it is:

http://shripriya.com/blog/2010/01/23/how-not-to-do-innovation/

The pattern:

1. Not getting it
2. Doing it -- but still not getting it.
3. Failing, but not understanding why