Archive for June, 2004

Don’t Kill Lead Developers

Tuesday, June 29th, 2004

I read my RSS feeds[1] using NetNewsWire, which is great. I see that Apple is use their distribution channel power to destroy that product. They are folding RSS feed reading into Safari

These moments are a real test for a company’s developer network program. They can reward the developers who were early to the market or they can quietly kill them.

Let’s be clear, don’t murder your leading developers! If you kill the ones that begin to succeed; using your hub-power what happens? It will and should frighten off other developers. These days developers have a lot of choices about where to play. In this world a developer network manager to silently kills leading developers on his platform should be fired.

Microsoft wasn’t able to learn this lesson and now they have had to replace a vast army of volunteer developer talent with a huge R&D lab. That won’t work.

Don’t under estimate the value of trust.

[1] Yes, yes, and atom feeds too.

Pointer Rotation

Tuesday, June 29th, 2004


It’s sad how much good material isn’t available on the web. Today I wanted to find a copy of Norihisa Suzuki’s paper Analysis of Pointer “Rotation”. I have access to a good library’s electronic subscriptions; but this paper was printed in 1982 which is too long ago. It appears that if I was an ACM member I could get it. Sigh.


It’s a nice little paper that shows that if you limit your pointer manipulation to rotate and shift you can make the chance of memory leaks less and the programs become more transparent; well they do at least once you get used to this as a programming convention.


For example I think it’s almost impossible for this routine to have a memory leak because the pointers have no way to escape. Rotatef swaps pointers but it can’t lose one.


(defun shuffle-vector (v)
"Return copy of vector with elements shuffled like a deck of cards."
(loop
with result = (copy-seq v)
finally (return result)
for i from (length v) downto 1
as j = (random i)
do (rotatef (svref result j) (svref result (1- i)))))


Norihisa also wrote a fun paper on extracting 3d objects from 2d line drawings, or at least I think he wrote that paper.

When it Breaks

Tuesday, June 29th, 2004


With few exceptions the QA organization and Engineering organization in software houses are given separate management chains. There are assorted rationales for this. Some firms like to set up the two in a kind of competition in preference to having them working in common cause to create good software. Some firms think of QA as a kind of auditing function who’s role is to temper a presumed tendency of engineering to fraud or self delusion. Some firms do this because they have put the engineering managers into a incentive structure that makes them likely to cheat to ship on time and they need to compensate for that.


This organizational choice seems results in a tension. The two groups are torn between their common-cause, i.e a great product, and the day-to-day competitive games that are a result of the organization structure.


Consider what happens when a bug is found. It’s an illustrative example of how short term reward structures can generate polarization between two groups.


When an engineer encounters a bug his reaction is to fall deeply into a trance state. This is the hunter’s mental state. He slows time down. He rises slowly and closes his door. To the hunter that moment is very valuable. He is in the presence of his prey. Even if it gets away all the information at hand is useful for stalking it tomorrow. The reward he seeks is a dead bug.


When the QA engineer encounter a bug his reaction is to shout hosanna. He bursts from his office to tell the boss. The reward he seeks is a bug sighted. To the software engineer this reaction is totally inappropriate. Yes, sighting the bug is a very key exciting moment but because the reaction lays waste to that very valuable moment.

The software engineer takes that exciting moment’s energy and channels it inward seeking a fugue state. The qa engineer takes that moment’s energy and channels in outward seeking a celebration.

The organization structure just amplifies this. The QA engineer goes to his boss; who gives him a warm smile. The QA boss goes to the engineer’s boss and gives him a sly malicious smile. The Engineering boss simulates a gratitude for the valuable sighting. He then simulates the engineer. He asks if they made any effort to stalk the bug. “Can you reproduce it?” “Do you know exactly how it happened?” The QA boss thinks: “Ah you always want us to do your job.” They smile at each other in the shared knowledge of the absurdity of their situation. Later the engineering boss mentions in passing to the engineer that there is another bug in the bug database.

The only way to breakdown this is to allow the QA engineer and the software engineer into more intimate contact. That allows the QA engineer to observe and them model the behavior of the engineer. They they can share the reward to killing the bug. Which is; of course the common cause. Of course, you’ll have to set aside whichever adversarial model you bought into when you established the separation of powers. Such organizational change can be tough.

RTFB

Monday, June 28th, 2004

It was inevitable. Today I was told to RTFB.

The Five Roles of Identity

Monday, June 28th, 2004

At it’s heart the problem of network identity is how to manage the model of the user available to web sites. User’s dream of a design that’s explicit, practical, and respects their privacy. Web sites covet different aspects of the user-model model. The fashion web site may desire to know the user’s hair color. The travel web site may desire to know when your employeer is planning a summer shutdown. The bank site may desire to know a statement of account of your current mortgage.

The demand for better models of visitors is what drives the market for solutions in the identity market. For example it’s what keeps DoubleClick in business. DoubleClick aggregates a statistical model of users from their browsing habits and then sell that to web sites. Web sites then use that to target their marketing. For all I know if you tell one of their clients your hair color then DoubleClick may well add that to their model.

Such implicit, statistical models of users don’t scale up to handle the revealing of more serious information (i.e. medical records, mortgage statements, video rental records, etc.), because of regulatory protections. Sadly some cases these regulatory protections are no more solid than the community expectations. I would certainly make a fuss if L.L. Bean sold information about my pants size to Amazon; but I wouldn’t actually be surprised. Few of us are surprised that if you reveal your a wish list or rate a product at Amazon it effects how they customize the web site for you.

The design challenge here is how to make the management of this revealing more explict. Something that users can understand, manage, manipulate, control. Something that regulators can then write practical rules about. Something that can be governed well. Something that tempers how much power concentrates into a few hands. If such hubs are absolutely necessary we presumably want to assure they are well governed. Tough problems.

Any solution will have to respect and balance the concerns of all the market particpants. Broadly there are five roles in this passion play. In the long run none of these is weak. Users, though, tend to be slow in exercising their power.

IDFiveRoles.png

Intermediaries get a lot of the attention here. DoubleClick, Passport, or Gator are comercial examples. These players dream of solutions that tend to concentrate the power in the market into their hands. The regulatory foundation also gets a lot of attention. That includes: standards bodies like the Liberty Alliance; pseudo-standards certification organizations like eTrust; governments (e.g. EU’s privacy regulations). The regulators tend to dream of getting a single standard to “rule them all.” They also tend to work to limit how much market concentration emerges in the roles above them.

The solution vendors, i.e. the folks that don’t actually run services but instead provide tools to those that do, may dream of owning the entire market but they are also very interested in assuring that a large number of customers for their tools survive. There a huge number of examples of in this role just to pick to random examples: the authentication tools found thru-out the open source middleware community; and Novell’s Oblex solution that is widely used inside firms. There is a notable subgroup in the solution provider space, the patent holders. Note also that standards bodies often provide a means to aggregate a patent portfolio.

Many real world examples are hybrids of these five classes. For example Yahoo, which is primarily a site, also does authentication ala Passport for some partners. These hybrids seem to have internal tensions between their roles.

Market concentration in all these catagories is, presumably, power-law distributed. For example DoubleClick and Passport are both in the top hundred traffic sites.

Interesting market, interesting design problem.