I was drowning into the abyss of the Italian bureaucracy in the last few days, going from an office to another one to fetch the papers needed to ask for another paper. A notary public asked me to get papers from the local registry office. The data was on paper, so the officer wrote an official document with a typing machine (a mechanical one). Of course there was something wrong in it, but since it was the referring to the notary’s county of the original document author and the notary was the same that asked me for the document (in other words, he asked me to get something he wrote) I hope this is a minor mistake…
The second paper (same papers I already had but I needed a fresher timestamp on it) forced me to go to another municipal office, where they told me
- I had to go to the land registry office (is cadastre the right word?) asking for some maps
- I had to pay €100,00 at a post office
- I had to buy two special stamps worth €14,62 each
Then I went to the post office to pay the €100,00 and buy the stamps. Obviously, there were no stamps of that size, so the lady started trying various combinations of different stamps (in a variant of the knapsack problem) to achieve the exact sum of €14,62. Welcome to the third millennium!
I then brought the maps back to the first office and they told me most of them were not needed for my type of request (grrr), so they just took one. I am now waiting the phone call of another officer telling me some papers are missing.
Ok, I might be a sort of a strange guy but I can’t help it: every time I go to a public office I start thinking about it in terms of OO modelling. It just doesn’t make sense to me that all of a transaction complexity is put on the user shoulders. It’s exactly the same problem you can face with badly designed interfaces in server code.
A server class (as the name states) is supposed to serve multiple clients. A good design decision is to hide complexity behind the server class API, so that you can write simpler clients. Since clients are written in different context and times, you pay once on complexity on the server side and save every time somebody writes client software.
Bureaucracy is normally doing the opposite: to achieve thin processes on the server side (enabling eternal coffee breaks), officers are moving the burden of complexity on the users: forcing citizens to locate external services, pay (in the silliest possible ways).
The more I look at it the more it doesn’t look like a way to save time at all: if a frequent connection has to be established between two separate offices, then using the citizen (which is 90% of the times doing this thing for the first time) is the most inefficient way of all! Citizens have to be trained to go there and ask that and that, and this is a repeated waste, citizens are not experts so they could make more mistakes than trained officers on a standard procedure, so the process results more error prone.
Can anybody do something about it? Unfortunately this is pretty hard, because requires somebody with a pretty large scope, authority, and completeness of vision: a dictator? An emperor? An alien from a distant planet? Since crossing organizational borders or ruling the empty spaces is one of the most difficult management activities, I am pretty pessimistic about that.
Test Driven Bureaucracy
In the OO world, the best way to achieve a simple API is to develop in a test-first style. This way the developer thinks first from the client perspective (resulting in low complexity of the desired process interface, mostly a money for paper bargain), and then implements the service, keeping most of the complexity behind the server interface.
I just wonder how a similar approach might perform if applied to bureaucracy, I guess we’ll have a lot of surprises (in Italy whole institutions are totally useless) by crossing a test driven methodology with a strong OO-like role/responsibility analysis. As the picture shows, even if pessimistic, I haven’t lost all my hopes.
Tags: OOD, TDD, Test Driven Development