Implications of the Power Law

I’m trying to capture all the thoughts triggered by the SPA conference before the ACCU conference in a couple of weeks time. One of the topics that resurfaced at SPA was the Power Law. Or rather, the fact that software source code and program execution follows a Power Law distribution. If you’ve not come across this before it is worth knowing.

Most (educated) people are familiar with the standard distribution, or bell curve. And the idea that most values cluster around a mean with most data falling inside a standard deviation. It looks something like this:



(Thanks to Petter Strandmark and Wikipedia for this image.)

Well there is another distribution which is called a Power Law distribution. It looks something like this:



In other words there are a few very large numbers and lots of very small ones. Most values are small, if you calculate the average its going to be small because there are so many small values the few large ones get averaged away.

As a result you get the long tail that seems to get so publicity. The 80-20 rule, also called the Pareto Principle is an example of a Power Law but this is a relatively mild form. Some distributions may be 90-10, 99-1 or even higher.

Well it turns out that software follows this distribution. If you take a source code base and count the length of each function you will find a few long functions and lots of small functions. Perhaps not every time but in general this is the case. (I’ve been told this several times and believe it, but I can’t put my hands on an reference to prove it, if anyone can please let me know, more importantly if its been disproved please tell me!)

It also turns out that program execution proceeds in a similar fashion. A few functions account for most of the execution time. Not necessarily the long functions I just mentioned, they could be short.

And it turns out that object graphs in OO systems follow the same pattern. James Noble has some work on the power law in Java systems - systems which conform to the power law are said to be scale free. As this paper points out the web itself conforms to this law.

I’ve been thinking about this for a few years - every since Kevlin Henney and James Noble explained it to me in fact! - and SPA gave me another boost when Michael Feathers mentioned it again. This actually has some quite important implications for software development.

Obviously this law has implications for performance optimisation: find and optimise those few functions where the time is spent.

It explains why major bugs can remain hidden for years and years. Because they exist in a function which is very very rarely used. The program crashes very occasionally. Of course if way the program is used, or the data changes, you might start triggering the bug far more often.

Most changes to a system will occur in a few places. Most of the system will remain stable and unchanging. Therefore it makes sense to refactor those parts of the system that do change and leave the rest.

Perhaps most importantly this law also completely demolishes the argument that you can’t retrofit unit tests to a legacy system. I regularly meet teams who say: “We agree that automated unit testing is good. But our system has 1 million lines of existing code and we can’t cover it with unit tests.” They then usually continue: “Therefore we can’t refactor or apply any of the other principles of Agile development.”

But when I have worked with teams that start to add unit tests to a legacy system they quickly find the tests pay for themselves. Even with a few tests in place there is a pay back. The power law explains this: because most changes happen in a small amount of code, putting tests around that code now will benefit you very soon. Most of the system is not changing so it doesn’t need tests. Of the 1 million lines perhaps only 10,000 changes regularly. As soon as you have 1,000 covered you see the pay back.

It is difficult to know in advance which parts of the system need tests so you might as well add them to anything you are working on. Just because this code hasn’t changed in the last year doesn’t mean it won’t change again soon. The fact that you are working on it shows it is more likely to change than most code. Save your time guessing what will change, just test it.

I’m also starting to see the Power Law elsewhere. It has long been noted that some developers are far more productive than others. 10, 20 or more times productive depending on who you read. Is this another Power Law at work?

I looked over the blogs (of individuals) I subscribe to on Bloglines this morning and made this graph:



This is the number of readers subscribed through Bloglines to the blogs I subscribe too. Joel Spolsky leads with 43,000, Robert Cringely weight in at 19,000 and Guy Kawasaki is a distant third at 3,300. Most of the blogs (including this one) are in the long tail with less than 10 readers.

I think I also see the Power Law at work in employment of IT people. A few people stay with a company years and years and years. Most other people average 18 months or so. Apparently once you’ve been somewhere for 7 years your chances of changing employer drop to near zero.

Some features in a program are used so much more but at the requirements stage it is difficult to know which these are and which are in the long tail. So the Power Law is at work in requirements too. The trick is to work with the law rather than against it: us a little-bit-and-often development and release strategy. Don’t front load your projects with requirements. Do a little, release a little.

It seems the Power Law runs throughout IT, unfortunately many people have internalised the standard distribution and use this as the, sometimes unconscious, basis for making decisions. Decisions made on a standard distribution are wrong. We need to learn to think in Power Law distributions.

Agile software development with Kanban

A lot of people in Agile circles are talking about David Anderson’s Kanban software development technique. To be honest I’ve looked at some of David’s online material and I haven’t really seen anything that new. But then, I’ve never spoken to David or seen any of his presentations.

So I took the opportunity at SPA to ask Steve Freeman about it. Unlike me, Steve has spoken to David so here are some of the points I got:
• Kanban teams have given up on planning and estimating entirely. The activities took more time than they were worth. Prioritisation is - as far as possible - handed back to the business. The highest priority is simply done.
• Kanban teams have a number of ‘slots’ by which I think they mean ‘tasks they can be working on at one time’. The business decided what to put through these slots.
• Teams track how long it takes for a piece of work to move through the system. I guess they just note the start date and end date. They can then tell what their throughput is which replaces the need to estimate.
• Work is tracked by cards on a board. This visibility together with the flow measurement helps show where the bottlenecks are.
• The business may (i.e. not all teams do this) offer the business a ‘Silver Bullet’. The business can use this to cheat: to fast track a feature through the system, to do a feature without any of the usual pre-work, or such. However, the business is only allowed one Silver Bullet at a time.

It all sounds very interesting and I hope to hear more. And if anyone reading this knows any more - or thinks I’ve got something wrong - then please add your comment.

According to Steve, David is finding that his bottleneck is not development. The bottleneck is earlier, its with the business deciding what to do and what needs to doing. This is something I have observed myself. In fact I thought I had written a blog entry on this subject, perhaps with the title ‘The Bottleneck has moved’ but I can’t find it so probably I haven’t written it just thought about it.

Anyway, I’ll say it now: The Bottleneck has moved.

In my own experiences with my Blue-White-Red agile method, I found that while it took time for developers to do work this was simply leg-work. More developers more work. Quality improvements (unit testing, code reviews, etc) helped and these made the teams more productive. But when ever the developers needed to consult the business (i.e. product management) things slowed down. Or, developers took the wrong decision and re-work resulted.

And if we want to practice Lean development then we can’t waste time building the wrong thing. We need the business to support us.

Over the last 20-30 years developers have got a host of new toys to make them more productive: their own (fast) machines, more productive languages, nice IDEs like Eclipse, and so on. Surely some of this technology has boosted their performance. On the other hand, the pipe coming into development hasn’t go any bigger. If anything it has got smaller.

What strikes me about Kanban is that it requires more business buy in, more business acceptance of the method and requires the business to know more about its role and what it wants. This is good because it makes development more responsive to the business.

This is entirely what I would expect because, while Agile/Lean can improve development alone, it ultimately needs to exist in an Agile/Lean environment. If it does not there will be tension, eventually the organization will kill its Agile development or Agile development will infect the wider company. This might be what David is seeing (or creating!) with Kanban.

Back from SPA

I’m back from the SPA conference. As usual I learned more from the conversations between sessions than the sessions themselves. To be honest, I was a little disappointed with the session selection. This might be more a reflection on my existing knowledge and experience than the sessions themselves. Still I have a lot to think about and I’ll do some of that thinking here in this blog.

For me the highlight of the conference was Michael Feathers keynote “Big Ball of Mud: Economics and Legacy Code”. The scary bit of this is that Michael’s thinking mirrors my own thinking over the past few years. Central to this is Conway’s Law.

I’ll apologise now. It feels like all roads lead to Conway’s Law, I almost find it impossible to give a presentation to engage in a long discussion without seeing Conway’s Law in action. Melvin Conway originally discussed the idea in 1968 but it has lain, almost forgotten, for much of that time.

My own presentation at SPA went well. I was again working with Lise Hvatum with whom I explored Conway’s Law a few years ago. This time we looked at The Knowing Doing Gap. This is the gap between learning something and acting on it, particularly in organizations. The session was well received and we were very happy with it. I promise to upload some results soon.

Lean Product Development references

After yesterdays blog posting I had a comment from ‘Brave Heart’ asking for some references on Lean Product Development. I’m more than happy to help and normally I’d reply direct to Brave Heart. But... I can’t find your e-mail address on your posting or blog. So that means everyone is going to see my recommendations...

The only book I’ve read which is dedicated to Lean Product Development is Michael Kennedy’s Product Development for the Lean Enterprise. There is some additional information in Machine that Changes the World (little bit dated now), Lean Solutions and Thinking Beyond Lean (also getting a bit old) but not a lot. I believe there are a couple of other books dedicated to the Toyota Product Development System but I haven’t read them.

I think you would benefit from looking at some of the literature from the software community. In particular Mary and Tom Poppendieck’s books Lean Software Development and Implementing Lean Software Development.

From there you have to decide if you want to look at Agile software development. I think of Agile as an application of Lean, which I talk about in my own book, Changing Software Development. If you do then SCRUM is going to be of more interest than XP or some of the others.

This is because SCRUM has its roots in the knowledge management - specifically the theories of Nonaka - and these link up with the knowledge thinking behind Lean Product Development. Which brings us full circle back to Kennedy. As Kennedy points out, Lean Product Development might be better described as Knowledge Based Product Development.

As for research, you might want to go and watch some Agile or Lean teams in action. Its probably easier to find teams which consider themselves Agile than Lean. You’ll want to look at how their activities differ from ‘traditional’ product development.

I hope that helps.

Brave Heart, please drop me e-mail (with your address) if I can be of any more help.

News, Conferences and a Project Management revelation

This blog has been rather quiet for the last couple of weeks, and most likely it will be quiet for the next couple of weeks. This hasn’t been for a lack of interesting things to say, quiet the opposite. In the last few weeks I’ve had insights coming left, right and centre. However, I haven’t had much time for blogging.

As I said at the start of the year I want to divert more of my writing into other projects. So this entry is here as a place holder and a preview of some stuff to expect. So please forgive me for breaking my one entry, one idea rule.

Those of you who know me off-blog will know I spent most of last year working with an Internet TV (IPTV) technology company. Some consultancy actually continued into the year, mainly with the CEO. Well now I’m please so say I’m going to get involved in IPTV again. I’m going to be doing some work with one of the major players to developer a completely new IPTV platform. Should be fun.

After XP Day last year I suggested that media companies are more open to Agile methods many other companies, specifically, banks. I am more and more convinced of this fact. Underpinning this is that fact that companies that use the traditional (broken) methods are still in business, these methods have brought them some success and fit with their business model - or their business model has been changed. Therefore these companies have little reason to go through a difficult change.

At ACCU London last month someone asked me: Why do banks have so many bad systems? It was that moment I realised: Because they can afford it. I hope to expand on this topic soon.

I’ve been busy with EuroPLoP 2008 and I’m at SPA 2008 next week, both look like being a good conferences. Then I’m at ACCU 2008 a couple of weeks later. Both of these will produce some reflections in this blog.
        
I’m going to be writing more about Project Management in the near future. Readers of this blog, and those who know me, will know I have been critical of them in the past. And I promise to carry on being so. But...

During the last two week I have taken Project Manager training, not just any training, PRINCE 2 certified training. Yes you read that right. Barring any surprised form the exam I took today I expect to be PRINCE 2 certified in the next few weeks.

So, why did I do it? Did I have a labotomy? Well it wasn’t an easy decision to spend nearly £1500 on the course but here’s why:
• I’ve criticised Project Managers in the past but this has been unfair, I haven’t really known what they should be doing, only what they do
• Increasingly I find that I’m asked to do Project Management roles, so the training should help there.
• More organizations look to PRINCE 2 to show you know about Project Management. To impress them you need to tick that box.
• I’d really like to understand how formal Project Management compares to Agile, and whether it is possible to bridge the divide.

I’ll write more about this soon but some immediate thoughts.

I had to do two courses for two exams, one last week and one this week. Consequently I’ve met over a dozen other people taking the same course and exams. Almost everyone of these people was an independent (contract) Project Manager in the IT sector. They were sending their own money to go on the course, and foregoing even more money by being there. Why?

Because increasingly PRINCE 2 is becoming a necessary qualification, if you don’t hold it your CV won’t get beyond the recruiter or HR department. PRINCE 2 fans are probably delighted to hear that. PRINCE 2 is wining! But actually I think its a very dangerous development.

This is because PRINCE 2 is massively risk averse. Of course PRINCE 2 practitioners would probably say “No its not, it just identifies and managers risk, you decide the risk level, isn’t that sensible?” but actually the very mechanism is risk averse.

Why is this dangerous? Because most companies - unlike the Government who developed PRINCE 2 - want to make a profit. Economists tell us “Profit is the return for Risk”. So, remove the risk and you remove the profit... more on this shortly.

Interestingly nobody on the course expected to actually use PRINCE 2. Even those sent by their companies (about 2) didn’t. So I don’t think PRINCE 2 is increasing in use, its just the qualification that is being asked for more and more.

Second insight. PRINCE 2 is not reflective, it considers the cost of projects, the cost of work but not the cost of itself. To run a full blown (or even half blown) PRINCE 2 is going to cost you a lot in administration and paperwork. That’s before you count the missed opportunities.

A few years ago I found myself introducing Agile at a company which hired a PRINCE 2 manager. We didn’t get on. We were both trying to do good for the company, and in many ways our prescriptions matched but ... well I’ll explain where PRINCE 2 and Agile match soon, and I’ll explain why they are incompatible too.

Somehow I got cast as the zealot. Some people came to believe that I wanted Agile, Agile, Agile. He never got cast as a zealot, that only dawned on me this week. Actually advocating PRINCE 2 and its practices the way he did was every bit, more so, as zealous as I was. But...

PRINCE 2 is so respectable nobody will call you a zealot for advocating its use. Its like suggesting you play Bach or Mozart. How can anyone object? Its respectable. Agile on the other hand is punk, its putting a safety clip in your nose and taking risk. No wonder I was seen as the bad guy! Now, once my certification comes through....