Category: Uncategorized

How many times have you heard employers or politicians talking about empowerment?

They’re going to give you permission to make decisions that affect you, or perhaps the people you serve. They’re going to allow you to organise things in a way that makes you feel happy with what you do, gives you the autonomy to do it right. Oh. That’s big of them, isn’t it?

This rests on some fundamental fallacies:

1. In order to have any capability beyond some repetitive mechanical work someone has to give you permission.
2. Someone has to pick you, and other people (therefore) have to wait.

Think about it – did Gandhi ask anyone for permission? He saw a problem with the world and just started doing whatever he could to change it. I went to Thinking Digital in May and one of the talks towards the end was a 15 year old who had come up with a cheap test for pancreatic cancer that will find early stage using carbon nanotubes, antibodies and filter paper. Wow.

He’s bright, very bright. But lots of other people are too. He was upset by the loss of a relative to this disease and decided to do something about it, he read a lot and came up with some things to try. Then he badgered some medics with research facilities until one let him come and try to develop a protocol.

It works, I hope it will come soon too. But the point I’m making here is no-one told this fantastic young person no. No-one gave him permission. He just went and did something that makes the world a better place.

So, the next time someone offers to empower you tell them where to get off. Pick yourself.

If you work in a way that creates systems and processes where human beings make human decisions then empowerment is not needed, permission is not needed. Grab that filter paper, grab those nanotubes, talk to that person.

DO IT.

Since I first made this post, which is a sketch of an idea I will develop further in Unicorns in the Mist‘s next outing more things have occurred to me that I wanted to share here.

I was chatting on Facebook and realised that I believe empowerment is also insulting. To clarify:

Insulting to the “empowered” – as in “you’re no longer too child like to look after yourself”. My take comes from a lot of the rhetoric you used to hear when people who had been disenfranchised by poverty or some disability where being ‘empowered’ by the state to make bogus ‘choices’. Instead of addressing the real need for creating systems that meet and help their needs they were so powerful they can fill in a survey. This is of course a simplification but I hope it helps getting the point across.

And, of course, the flip side of being given permission is that it also allows the giver to take it away again. That’s big of them too. It assumes a paternal relationship and distribution of power where the empoweree (sic) has to rely on others to validate what they do. Just take a look at the whole crazy gang of incompetents and buffoons that try to run your life and think about how little permission they can ever grant you, or anyone else.

One of the other speakers at Thinking Digital was talking about opening up government data, which is a cause dear to my heart. Apparently at least some of the nominal owners of this data are concerned that people like us, the poor unwashed masses, might draw the wrong conclusions from this data. Wrong in terms of whatever ideology or spin they want to put on it. So the empowerment that this data may bring should be conditional on whatever they think we should be saying or knowing. Yeah. Bless them.

As Deming is reputed to have said in Jesus Christ we trust, all others must bring data. I’m not a Christian, but the rest of the sentiment is sound 🙂

Implementing Domain-Driven Design by Vaughn Vernon
My rating: 4 of 5 stars

I think this is a great book in terms of the ideas it promotes, but for me somewhat flawed.

It’s billed as a companion to Domain-Driven Design: Tackling Complexity in the Heart of Software and as such is less abstract and works through some case studies to get to the meat of what that the original DDD book only hinted at and actually went round and round a lot.

For me it harks back to a lot of things I have recently read and done, in particular the design process for good (for some definition of the word) object-oriented software, as Practical Object-Oriented Design in Ruby: An Agile Primer covers really well. Sandi talks about OO being all about the messages, and you end up with well put together clusters of objects if you start from there.

DDD comes at the problem from a different direction, instead starting out at a higher level of abstraction in the problem domain, rather than creating objects and seeing how they work together. It has some tools for uncovering what the business wants. It starts by looking for a ubiquitous language and making sure that the development and testing silos are speaking the same language as the business.

Of course, it’s more complicated than this. Vernon gives the example of a book publisher. The people commissioning a book need different language to describe setting up their relationship with an author and paying them, the people creating the book and illustrating it again have different needs, and distributing and stocking the final physical product is different again. So, if you were trying to create some kind of master book object that met all of these needs you may well end up with conflicting terms, and indeed needs expressed by those terms.

To get round this you break your problem space into bounded contexts, and these become functional areas which each have the own ubiquitous language. This gets around the weird mashing together of functionality that quite often makes large systems a complete pain to maintain. Each area manages its own needs and translates, as and when required, if it needs to talk to another. I believe that a pretty reasonable SOA architecture will fall out of this in the end.

I think I’ve understood this process after a hundred pages or so, but I don’t want to read any more of the book. I had the same problem with the original DDD book as well. The core concepts are pure gold, but the presentation is extremely repetitive, wordy and really hard to read for useful content. Both books needed more pictures and a catalogue of the concepts, organised rather like Martin Fowler’s Patterns of Enterprise Application Architecture – with about 100 pages of well-written and illustrated chat with the remainder of the book taken up with a list of the patterns in detail once you know how to use them. In fact, both books need a damn good edit.

The other thing that I find really annoying is things like bounded context, once introduced, are always capitalised Bounded Context. Maybe it’s just me, but the constant capitalisation of a concept really breaks the text up and interrupts the flow. The original DDD book does this as well. This capitalising thing is a disease caught from an old-fashioned style of writing, common to people who read the King James Bible, which was written at a time when you would capitalise nouns. Myself, I use italics when I introduce a concept and then either abbreviate it to, say, BC, or just use it as normal. This capitalisation reads like the old pompous religious tracts handed out by slightly demented people going door to door when I was a kid, and I didn’t like it then either.

So I would like a list of all of the Ideas Expressed With Capitalisation and how to use them, and about half the amount of text without all the waffle. I gave up because I got the concepts and the rest of the signal to noise was too low.

The cartoons of the cowboys make no sense to me either, and there was a weirdly old-fashioned feel to the one offering your stakeholder a cup of coffee to talk to them. You could probably put each chapter into about three paragraphs and not lose a lot of information.

So, I gave the book four stars because the ideas are incredibly useful, but be prepared to struggle with keeping awake between the useful nuggets.

Incidentally, if you want Sandi’s book, please buy it from her site.

View all my reviews

That’s really hard. If there was one for emptiness it would be easy. Not space though – that one’s really annoying 🙂

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