There are some upsides to the recent massive data loss from the UK’s tax authority.
First, even though there was a delay, they did admit the loss and someone senior took the rap. There are too many organisations where this kind of news would never be allowed out.
Second, this breach has been large enough to make the headlines raising, I hope, public awareness of the issues. Of course, the real scandals are systemic rather than this one incident, as Ross Anderson pointed out this was “an accident waiting to happen”. Centralising all the data while casualising the workforce is not safe. If one junior clerk can copy all this data, then we must assume that others already have, but secretly. At the same time, one reason this data is so important is because too many retail institutions have weak procedures when handing out money and the credit agencies are not answerable to the people they rate.
A final benefit is the excellent opportunity for satire. This eBay auction (now withdrawn) has been preserved on The Register.
Update Police have concluded that only one person in the world would want to know the names and addresses of all the boys and girls at around the end of the year. They are now widening their search to the North Pole.
Thanks to Naresh Jain I’ll be presenting a tutorial/worshop on TDD with Mock Objects at Agile India this Sunday, 25th.
Presenting this far from home is still a thrill for me and, providing I can hold up against the jet lag, I’m very interested to see how our material will be received.
Here’s a great example from Robert Cringley of why crisp requirements aren’t. At least not in almost any system that’s likely to be useful. I think it’s worth quoting the relevant part at length, there’s some other stuff about Google and mobile phones in the original article. Hands up everyone who’s worked on a system that assumed that a social security number identified a person…
While politicians and the U.S. Census Bureau may disagree on how many illegal aliens are living in the United States, the big credit reporting agencies have a pretty solid handle on the number and it is 17 million. That’s 17 million adults of unproved nationality who have ongoing financial relationships with businesses or — believe it or not — governments. […] But it isn’t in any way close to the total number of U.S residents who have financial identities not tied to a Social Security number. That would be 37 million, meaning there are 20 million participants in the U.S. gray economy who aren’t illegal, who are legitimate citizens. This means about 10 percent of U.S. residents are financially invisible, or think they are.
There is a lot to be learned if you think about these numbers. […] The first thing to be noticed is that these supposedly invisible people have been, well, noticed. The credit reporting agencies have a handle on total numbers and have a lot of information on specific individuals. So members of the gray economy are, for the most part, not invisible at all, just difficult to identify as individuals. But thanks to data mining down at the credit bureau, it is getting harder and harder to hide.
A lot of this sleuthing comes down to a surprising artifact, the Social Security number. One would think that surprising for an economic class of people best known for not having Social Security numbers. Ah, but they do have Social Security numbers, just not their own. You need a Social Security number to sign up for utility services, for example. No Social Security number, no electricity, gas, phone, or satellite TV. So what’s a poor alien to do? They go down to some local hangout and BUY a Social Security number to give to the utility. This has to be a legitimate number or it won’t fly with utility computer systems, but does it have to be the customer’s own number? Good question.
Here’s where we have an interesting business ethics issue. Say you are the electric company and someone tries to set up service using a Social Security number that already exists in your database and is clearly borrowed, bought, stolen, or simply made up. What do you do? Most utilities go ahead and set up the account, because to them what counts is whether the new customer will actually pay that bill and it turns out that people operating on such borrowed numbers are more reliable bill payers than the rest of us. They can’t afford to get in trouble with the electric company because that would draw attention to them. So there is a tacit agreement between the parties that a Social Security number must be provided because that’s the rule, but if it happens to be someone else’s Social Security number, well that’s okay.
The funny thing about this is the impact it has to have on the person who was originally assigned that Social Security number by the U.S. government. Rather than hurt their credit it actually helps because there is so much evidence that they are good at paying their bills.
Of course the credit bureau notices something and that’s why they are so able to estimate numbers in the first place. They know what Social Security numbers are being overused and can probably even trace the genealogy of that number as it makes its way across the country. Here’s an amazing fact: some individual Social Security numbers are in use right now by UP TO 3,000 PEOPLE and it isn’t at all unusual for a borrowed number to be used by 200-1,000 people at the same time. […]
As you discovered when you were the project, your nerd’s focus can be deliciously overwhelming, but it will stop. Once a nerd believe he fully knows how a system works, the challenge to understand ceases to exist and he moves on in search of The Next High.
While I don’t know who you are or why in the world you chose a nerd for your companion, I do know that you are not a knowable system. I know that you are messy, just like your nerd. Being your own quirky self will be more than enough to present new and interesting challenges to your nerd.
From The Nerd Handbook. All too true.
Michael Feathers has kindly cited Nat Pryce and me in his recent discussion about how asynchronous messages should be. He talks about the approach to coding that we like to take, which informed our approach to jMock. I love Ralph Johnson’s description of this as the “mystical view” of O-O.
I think both of us were influenced by functional languages. These days, I find a high proportion of my methods seem to consist of chained calls to other methods, with not many variables and a lot of closing parentheses—probably to excess.
What we tend to find is that we end up sort-of passing behaviour to the data, so it’s almost the opposite of the shell pipeline. This draws on the other neat part of functional programming, throwing around partially bound functions. The pattern looks a little like this: when an event happens, figure out who wants to know and create an object to represent them; then pass that object around the runtime until you find something that can feed it the data it needs. As Michael says, the substrate is relatively stateless which means we localise the coordination issues in just a few places.
The original mockobjects idea came from an experiment at Connextra where they asked the question, “what if we wrote objects without any getters?” My only addition is that you have to do it for a while before the effects start to kick in, anything will work in a small enough example. It’s obviously too extreme, but try it for a while.