CategoryUncategorized

Empowerment is a lie

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 🙂

Facebooktwittergoogle_plusredditmail

Review of “Implementing Domain-Driven Design”

Implementing Domain-Driven DesignImplementing 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

Facebooktwittergoogle_plusredditmail

Imagine you’re reincarnated as a unicode character. Which one?

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

Facebooktwittergoogle_plusredditmail

Unicorns in the mist published at last

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.

Facebooktwittergoogle_plusredditmail

Review of Why Most Things Fail: Evolution, Extinction and Economics by Paul Ormerod

Why Most Things Fail: Evolution, Extinction and EconomicsWhy 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

Facebooktwittergoogle_plusredditmail

Now I are Python koder too

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.

Facebooktwittergoogle_plusredditmail

Republished my novel Archive Fragments on Lean Pub

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.

Facebooktwittergoogle_plusredditmail

Running your Rails apps on a Mac

I keep making the obviously false assumption that people know how to run Rails apps on a Mac.

If you’re starting from scratch have a look here: http://railsinstaller.org/#osx – I haven’t looked at it, but it looks like it will take a lot of pain away. This post is for people who have an existing app running on an old version.

The following assumes that you have some kind of Ruby installed and some kind of Ruby gems that came with it.

Also, you’ve already got some Rails code, that may be running an old version of everything.

Install XCode if you need to

Start up a terminal and type

cc

If it gives you a command not found error then you need to download XCode from the App Store, fire it up, and then ask it to install the command line utilities. This can take a while, and google is your friend if you don’t know where to find things.

If you already have XCode then you just need to install the command line utilities, which are off on a menu somewhere.

Install RVM

gem install rvm

when it gets to the end of the install it will tell you what to do to your shell environment to run rvm properly. DO IT. 🙂 For reference see https://rvm.io/ If you are unfamiliar with getting things to run in the active shell after altering the shell startup commands, just close the terminal and start a new one, life’s too short.

Install the Ruby you need

In this exercise we want Ruby 1.8.7, so …

rvm install 1.8.7

Eventually it will finish and tell you the version it installed, e.g. ruby-1.8.7-p352

You may encounter some errors, where Apple have kindly set the default C compiler not to be the old GNU ‘C’ compiler but their llvm one. Cut the error message out and paste it into Google, then do what it says. 

These instructions might say that it can’t find the command that you put into the environment variable, in which case use whereis cc to tell you where the cc command is.

Any other problems, use the more command or an editor to browse the log file it says

Create a .rvmrc file in your Rails root

Let’s assume the Rails app is called brightstuff. In the root of your Rails app type

ls .rvmrc

If it finds something, have a look and see what it says, for the purposes of this exercise I’m assuming the file isn’t there. Type the command

cat “rvm use ruby-1.8.7-p334@brightstuff” > .rvmrc

Change brightstuff to the name of your app.

Now

cd ..

cd –

This takes you up and then back to the directory you just added the rvmrc to. If you have installed RVM correctly it will ask you if you want to use the .rvmrc. Say yes.

Now

gem install bundler

bundle install

This will set all the gems up for you in this version of Ruby, in a group named after your app.

Some people don’t use the gemset (which we have named brightstuff) and rely on bundle exec, but I’ve found this to be pretty bomb proof.

You can also install gems independently of the Gemfile used by bundler, I typically install things like powder (see below) like this, because they aren’t needed in any context other than development.

Start the Rails app

As is standard, you can start a development version of the app with:

bundle exec script/server

This will start the app on http://localhost:3000, you can use /etc/hosts and various tools (go look for them) to alias them, and start things on different ports.

Other things

I use the pow utility and it’s friend the powder gem to run my apps. http://pow.cx/

Facebooktwittergoogle_plusredditmail

Review of “Dancing with Dragons”

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 DragonsGeorge 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

Facebooktwittergoogle_plusredditmail

Review of Better: A surgeons notes on performance

Better: A Surgeon's Notes on PerformanceBetter: 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

Facebooktwittergoogle_plusredditmail

© 2017 Francis Fish

Theme by Anders NorénUp ↑