Author: francis

I’ve been working on Unicorns in the Mist for a while and, because I was ill, decided to get it out of scrivener and into the wider world.

It’s my take on applying systems thinking to getting projects and stuff done and is assembled roughly 50/50 from old blog posts and new material.

It’s free to download if you want to have a look at it.

Why Most Things Fail: Evolution, Extinction and Economics by Paul Ormerod
My rating: 5  of 5 stars

I think this is an important book, and I also think its message might be difficult for some people to reconcile their world view with. Ormerod sets his stall out to show that economists have presumed that the economy (and lots of other systems we think of all day every day) actually is a steady state, that markets exist as a relationship between buyers and sellers, with supply and demand following perfect curves that come from perfect knowledge.

Of course, as he points out, this is nonsense. Markets don’t exist in a steady state, there are too many factors that cause change. Ormerod cites work done that shows even if the steady state were to occur any kind of shock to it could take as long as a hundred years before it would stabilise again.

The classical view that comes all the way from Adam Smith assumes perfect knowledge, actors in the system need to know what every other actor is doing. This doesn’t happen, the textbook view that makes assumptions around marginal costs is bogus, a lot of the time businesses don’t know what they are, a lot of the time they don’t know what their competitors are doing, and as you can’t see into the future, even if they did it probably wouldn’t help because you still don’t know what your customers may want that you don’t do. Most businesses of any size or complexity tend to work using rules of thumb, and the MBA spreadsheets don’t help because they assume perfect information. Also, your customers might just not like what you have to offer this season.

He looks at work done on evolution. In particular work done by Raup shows that there is a power series relationship between the frequency of extinction events and their size. Other people have discovered that you can draw almost exactly the same curve if you look at business failures. This has some interesting consequences – if you play with these models and look at an arbitrary measure of ‘fitness’ in the Darwinian sense then a degree of cooperation is actually good for the long term viability of the system as a whole. Ultra competition forces prices down and isn’t good in the long run – neither is cost cutting.

The problem of perfect information is also addressed by looking at simple games, such as the Prisoner’s dilemma, played over many iterations and looking at what strategies win over the long term. As well as an arbitrary game involving where on a line you might place your ice cream stand to get the most customers. As soon as you have more than two players, and more than one time of entry into an existing market it becomes almost impossible to do more than work out what the graph of possible solutions to the problem is and understand the shape of it. If you are one of the players it’s hard to work out what to do.

Interestingly we have two extinction models – one is external shocks (the asteroid of dyno extinction fame), another is that a niche closes because of some other factor in the competition and a species dies out. Species are competing and cooperating (predators stop prey eating all of the available food and destroying the environment which means both species survive), so there could be a cascade from what looks like a relatively small cause. In fact, both happen, there is no either/or. But modelling this, predicting the future, becomes impossible. All you can do is look at the shape and work out how to cope with what may happen.

Ormerod concludes by giving an overview of the work of Schumpter and Hayek, that is often ignored.

The visions of the world articulated by orthodox economists and by Hayek are fundamentally different. Conventional theory describes a highly structured mechanical system. Both the economy and society are in essence gigantic machines, whose behaviour can be controlled and predicted. Hayek’s view is much more rooted in biology. Individual behaviour is not fixed, like a screw or cog in a machine is, but evolves in response to the behaviour of others. Control and prediction of the system as a whole is simply not possible.

Ormerod quotes several examples of systems coming up with robust solutions to problems (even the origins of the mighty US dollar) that weren’t obvious until they were left alone to find solutions themselves. A good example of this is the hub and spoke architecture of US domestic airlines that appeared after deregulation. It serves customer needs but no-one could have foreseen it at the time.

The central argument is that central planning doesn’t work and solutions that are workable and human come from creating environments where the actors can work together on solutions that benefit them. Essentially.

… it is innovation, evolution and competition which are the hallmarks of a successful system …
Schumpter coined the phrase ‘gales of creative destruction’. He argued that innovation led to such gales that the caused old ideas, technologies, skills and equipment to become obsolete. The question … was not ‘how capitalism administers existing structures … [but] how it creates and destroys them’. Creative destruction, he believed, caused continuous progress and improved standards of living for everyone.

This has serious and interesting consequences for policy makers – the models show that forcing too much competition between actors hurts the overall fitness of the system, and also protection does too. So most of the time they must resist the urge to exhort and fiddle – this comes right back to the work that Deming did all those years ago that no-one remembers and everyone should read. Four days with Doctor Deming

But if they resist the temptation to exhort and fiddle without enough information, if they don’t listen to lobbyists and make sure decisions are made locally by the people who know what’s needed. If they do all these things, we don’t need that many them and they don’t need to do much to keep things steady.

I’ve just started reading Antifragile, which addresses the other side of this equation, given that the world is very unpredictable isn’t it better to create institutions and systems that aren’t brittle from so much command and control mania and even benefit from small shocks and changes. I will return to this subject again in my next review. I think that I have accidentally stumbled on two books that complement each other. Ormerod’s work gives a mathematical, scientific background that looks across many disciplines to say some very similar things.

So, read this book, it will surprise you and leave you thinking about how we should do things so that failure is part of what happens but isn’t a catastrophe.

View all my reviews

I’ve recently taken on a gig where I am writing Python code because the work is mostly done in Python and they want it to be maintainable by the original team members.

I have to confess that Python was my gateway language into the world of non-rigid Java nastiness but this is the first time I’ve ever used it proper hard in earnest for money.

In my Ruby practice I’ve recently changed the way I write code pretty radically. I now

• tend to write very small methods that just do one thing, I write tests that test those one things. I usually write the tests first.
• I’ve also started using little lambda functions and passing them into other wrapper methods that just need to call the processing hidden in the lambda.
• Every time I see lots of assignments one after the other I’ve started using tap or returning to protect me from my own stupidity.
• When I see case statements I tend to create a little helper class
• I will create little classes inside the current class so I can just ask them about things instead of writing procedural code. I can also test them too if I need to.
• Really getting away from writing long methods full of procedural code. They are a sod to test and confusing to read.

Now I’ve done some Python I’ve realised that there are a few things I like:

• Files are modules, and namespaced. This is a little odd at first but I like it. It means you could do without classes if you wanted, maybe.
• I’m on the fence with objects needing to have self typed everywhere. I can see how it’s easier to create an OO style quickly if you force the coder to put self everywhere, but it feels heavy. It also feels right because you can’t do stupid assignment bugs like you can in Ruby, or rather the bug shouts out at you when you have.
• I like list comprehensions, but they seem really heavy after using blocks for years.
• I like how (like Ruby) you can pass references to functions around, and I think the syntax is superior.
• I like the built in help. Ruby’s is not built into the classes the way Python’s is and you often find yourself digging round on the web for a while when a couple of commands in the Python interpreter and you’re away.

I don’t like (as in … why?):

• I don’t like procedural-style conversion functions polluting the top level namespace, but I have understood that (for example) list is really a class that you initialise and isn’t really a function. It just looks like one.
• Ruby enforces a convention that classes (i.e. constants) all begin with a capital letter. It seems silly, but not having an enforced convention makes unpicking code harder than it needs to be. I think the first point would have been easier to get my head around if I’d been able to see that these conversion functions were actually class constructors. Java has the convention of upper case classes but doesn’t enforce it – this is a major pain, or can be.
• Python has a built in complex number type, but doesn’t have any native syntax for regexp. I was looking in the Python docs and there was some nonsense about not needing syntax because you don’t use regexp much and typing strings is fine. Utter crap, I use them way more than complex numbers. Plus if you want a complex type in Ruby it’s really easy to make one and just drop it in. Always having to screw around with strings is one of the things that makes Java so unbearable. I like syntactic sugar and syntactic checking, makes life easier and it’s relatively trivial to add in. Just lazy not to, and it shouldn’t be dressed up.
• Overriding methods like + and so on is a bit hard, because of the method naming. Not too bad, just irritating. 

I got a copy of Learning Python, and I’m about 40% of the way through it. No significant mention of objects at all yet. I mean, the word has been used, but not the thing. Just loads of procedural code examples. I’m beginning to think that this is a function of how the language grew. It was picked up by a lot of folk who were moving from hoary old procedural environments, like Fortran, and who were used to thinking in huge chunks of code. So it gets taught that way, and people pick up habits that are bad, and hard to improve upon. I’m almost tempted to put together my own book that puts the objects first, but don’t have enough time to do the things I need to do as it is. 

So the first Python module I picked up as an example of how to do the work I’m doing was 300 lines of procedural code. I ignored most of this and started with unittest and worked backwards into some simple classes that do a similar job in about half the code (not including tests). So it is possible to write nice clean BDD Python code, but doesn’t seem to be part of the culture. The examples aren’t very good.

I think it’s a good language and don’t mind using it, but there is definitely a problem with object orientation and design being treated as something for the adults and maybe only later that I think needs to be addressed.

I thought I’d try out the Lean pub platform and put my novel Archive Fragments up there. Over the next month or so most of my creative and technical work will appear there so that people can see it more easily.

It’s over 64,000 words long, and I hope an interesting read. 

Enjoy.

George R.R. Martin, A Song of Ice and Fire, 5 Book Set Series, A Game of Thrones, A Clash of Kings, A Storm of Swords, A Feast for Crows, A Dance with Dragons by George R.R. Martin
My rating: 3 of 5 stars

I have enjoyed the Game of Thrones series right from the beginning, but this book was very disappointing. The writing was very laboured in places, with characters repeating themselves, and there weren’t enough dragons in it for me. It also seemed to take far too long for anything interesting to happen, and when something happened it took a long time to actually effect anything.

The title is a reference to the various bits of royalty that have connections with the original Dragon Throne, but the dragons that Dany is bringing up don’t do much for 90% of the book.

I was also really interested in what was going to happen to Arya, but the answer was – “not much”.

And we finally meet the three eyed raven but again what happens? “not much”.

The book could have been 25% shorter and not lost anything, it needed an edit. Rather like the Harry Potter “Order of the Phoenix” it felt like it had been rushed and then left.

The cliff hanger ending was really laboured, and I’m not sure I can be bothered reading book 6. I also thought it was possibly the last book in the series and was irritated that a good number of plot lines are still dangling.

Not sure I care enough to read the last book, assuming there aren’t books 7 and 8 after it.

View all my reviews

Better: A Surgeon’s Notes on Performance by Atul Gawande
My rating: 5 of 5 stars

This book is an easy read but very thought provoking.

One of the most interesting bits was where he examines the difference between the average Cystic Fibrosis centres and the best ones. All human activity has a bell curve attached to it, but CF treatment is very well understood and systematic. So why does one centre have startlingly better results than another?

In essence the better centre didn’t compromise, they didn’t think that (for example) 80% lung function was good enough, the patients under their care were expected to have 100% or better.

It’s the difference between 99.99% and 99.5% – we’d all be happy with 99.5, but excellence is in the remaining fraction of a percent, because when you add this up over several years this tiny difference means a lot. The sums are simple 99.5 over 5 years will give 97%, 99.99 will still be 99.99 or thereabouts. If you take this up over a patient’s life of 30 or 50 years the difference would be even more apparent.

I’ve hit this in other walks of life, for example project management, where you maybe have a 0.9 chance of finishing on time every iteration. This means that the chances of still being on track are as low as 0.6 after 5 iterations – it’s just mathematics. When building software having a fire break every so often to deal down the technical debt and reset the projects is perfectly doable, but if you’re looking for excellence in medical care or some other industry that could kill people then you have to become fanatical about getting higher scores

There are plenty of other excellent articles in the book, the fight to eradicate polio and the crazy situation faced by doctors in India are really great articles, and I learned a lot about how we could really help the people in poor countries. I admire Gawande’s honesty about his own shortcomings, this gives the writing a validity that it would otherwise lack. And the nutty unjust system that is the law based compensation for medical errors, that wrecks the chances of the poor to get help and helps no-one but the lawyers.

View all my reviews

So here we are again, it’s the middle of the night and I should be asleep. Instead I sit here waiting for the evening to be over. It’s dark outside but for the street lights. I wonder which of the endless layers of me is writing this, what obscure trophism is pretending to be me right now, creating the narrative force that pretends to be I.

I could be angry or frustrated, or so many things at once. The mind is an endless running brook split by rocks. The streams join together and I emerges out of the wreckage of all of the conflicting pieces, a pretence of a coherent whole. One never sees this sleight of hand except when you do bad things. The doing and the justification rarely hold up when you place them firmly under the microscope. So few people ever do, they just stumble from one moment to the next, thinking they are thinking and deciding things. But it’s all the dance of chemical chimera.

Longer ago than you can count stars exploded and made the matter you are made of. You sit at the bottom of a gravity well, perfectly adapted to what is in front of you, the chain of circumstances, of causes and conditions goes back beyond even those stars.

They died for love, for love could never have existed without them. But they had no mind, no awareness to die for it. Just like sand accumulating on the beach, it is ineluctable and happens without a master plan. So too, this whirling of circumstances that manufactures I will be gone and never seen again. The Buddhist masters say that the lives connected with you are like bricks on top of one another, the wall would not stand without that connection: but I begin to feel that the bricks are just bricks, the connection is the connection behind everything – the fragile I just makes itself and leaves enough traces to allow another one to stand in its place with some of the same attributes.

So let it go, now, and embrace it too. 

I like Android development. But you go off the beaten path and, well …

I’ve written some custom ListView objects that get rendered depending on what kind of device is needed for a home automation app I’m working on.

So far so bad.

Now you need to be able to turn that device on or off.

Tricky.

On the phone’s screen there is a button for every item displayed, each showing the correct value. 

BUT … inside it reuses the object that has been created. I have attached listeners to the button that mean when you toggle it off or on it sends a message to the underlying device.

It does. But then it sends messages to ALL the devices of the same type, because I’ve attached the listeners to what is basically the same GUI over and over again. So it looks right on the screen, but underneath all that happened was things were set in the right order so they display correctly. Right at the end of the call chain it sets the value back just for fun.

OK – let’s get it to tell me the ID of whichever row was tapped and only allow commands to be sent to that device. Nope. The button has the focus and won’t tell it’s container there was a tap and I’ve tried all the suggestions google could find for me. So the listener doesn’t ever get fired.

I think I’m going to have to short circuit the views and create them by hand, so each is a separate object with its own button etc. defined with its own listeners.

List View is designed to work with thousands of elements of homogenous data that can be tapped on and treated as a unit. But actually, for the case where there’s only a few that might have other things on them, it just doesn’t work.

I’ll have another look on line tomorrow.

By the way – I’d lay money that iOS Table View has similar problems, before people start doing the fanboi thing.