Good enough

I was reading a blog post by one of my favourite authors talking about how difficult he finds it to hand in a manuscript.

"It’s a hard thing for me, letting go of a manuscript. Other authors are very matter of fact about it. But for me, obsessive word tinker than I am, I hate knowing that after a certain point I won’t be able to go in and fix things any more."

I feel something very similar when I'm coming to the end of a milestone and the code I've been working on is getting close to "complete". Because I am paid to create functionality and not art, it's actually possible for me to over polish the code. So I thought I would write about what goes through my head when I'm trying to decide if my code is ok. Obviously, the code has to meet the written requirements - otherwise it is deemed "not good enough" by QA.

Meeting the written requirements

• Obviously, the software I write has to meet the immediate functional requirements - it has to work as intended.
• It, usually, also has to meet the design requirements - it has to look right.
• There are also user experience requirements - it has to feel right.

However, the written requirements tend to deal with the tangible parts of the software. It now becomes a judgement call on the part of the developer whether the code she has written meets the required standards for the unwritten requirements - things like maintainability, readability, reusability, extensibility, architecture and test quality. How important these requirements are depend very much on what you are building and the time frame your are working in.

I genuinely believe there is more value in a developer who develops good quality software quickly, than code poetry slowly. I justify this by saying that after a certain level of quality in a piece of software the effort starts to out weigh the gain and the reason for putting the effort in becomes less about the software and more about developer ego. I think the developer who understands this and judges correctly when to stop is the better craftsman.

Meeting the unwritten requirements

Software is constantly evolving and it's sometimes not possible to come up with the "best" solution for a piece of code until after it's been in use for a while. We were seeing lots of forking in the code where data needed to be processed differently depending on certain circumstances, so we decided to write a more elegant method of dealing with this. I closed the code review in which the final outcome of the discussion was to leave the code unfinished and revisit it to see how it's actually being used. The more time that has past, the more I think that turned out to be a really good idea. We waited to see how other developers would need to use it and how some might try and abuse it. The solution we have now makes the common forms of abuse much more difficult, while aiding the current common usages.

The above is, in my opinion, an example of where good quality code really shines. The code doesn't just perform it's own task, it creates a process for other developers to quickly perform similar tasks. When given a new task, most developers will look at the system and see if something similar has been done before. At some point, your code will likely be used as a base for something similar, or a small part of it will be used as the pattern for "doing x" in the system. You can aid in this by making the code easy to read and understand. If it's loosely coupled, it'll be easier for other devs to work into something new and that new thing will likewise be loosely coupled.

I am a big fan of using tests to help other developers understand the subtlety of the requirements of my code. If I make an assumption during the development of some code and it turns out to be wrong, that's a test right there. If a future dev makes the same assumption and introduces a bug because my tests didn't fail - that bug is on me.

When trying to decide if my code is "good enough" yet, here's what usually goes through my head:

• Would I be ok seeing this code replicated through the system.
• Is this problem local to this code, or do I need a global solution for other devs to use.
• Is this problem properly tested.
• Can I justify changing this?

Arguing with stupid people

Changing your mind in response to an overwhelming argument is as fine a quality as it is a rare one. I was reminded of this fact yesterday in discussion with the current Mrs Ant. Then, again, today when a friend posted a Mark Twain quote I like and I thought it might make an interesting blog post.

"Never argue with stupid people, they will drag you down to their level and then beat you with experience."

Mental models

We all have a mental model of the world in our brain, our version of the world, our place in it (the centre) and our friends and acquaintances as satellites orbiting us. This model is super useful for us, as it allows us to play out scenarios in our heads before trying them out in the real world. For example, I am in a room with my boss and his boss. My boss makes a suggestion which I think is stupid, rather than blurting out that fact and suffering the consequences I can run a series of scenarios in my head, before commenting.

1. Hey Bob, 1963 called, they want their shit idea back, oh and November the 22nd says it wishes it was you instead of Kennedy.
2. Yea, nice one, or we could do x, might be quicker?

Now we run the simulations and go through the likely outcomes.

1. Bob loves a good roasting and respects opinionated people. Bob's boss looks like a hard businessman, just the type to take the hard line.
2. It's a pleasing answer, but it puts across two points, which makes me come across as uncertain.

It may seem unnecessary to state that this exchange all goes on inside my head. That the Bob referred to here is my mental model of Bob, and may, in fact, not represent the real Bob in every aspect. Yet the world is a complex place and we are often surprised when an interaction goes completely differently to the simulation. Unfortunately, we don't think very much about how poor a representation of the real world our mental model is. This is largely because we need to have faith in our simulations in order to act without undue hesitation.

Changing the model

Each time one of our simulations leads us ary, it causes us to restructure our mental model. This is fine for non weight bearing parts of the model, for example, realising you actually do like olives. For most people, there's not too much re-shifting of heavy mental furniture to accommodate this new fact. This shifting of mental furniture takes a great deal of mental effort.

If I can stretch the analogy further and imagine changing my mental model to switch my opinion of a co-worker to be like moving the sofa in my living room. As well as expending the energy to move the sofa, I have to adjust all of the things associated with it. My mental model must remain consistent, useful and operational in the same way my living room does. I can't just turn the sofa to face a wall and continue using it as is. I need to be able to see the t.v. and ensure I get enough light to read.

This effect is even greater when being asked to accommodate new information. This is why some of the most persuasive arguers will take the time to help you build the mental frame work into which they want you to place their new idea long before they ever get to the idea itself. In his excellent books Douglas Hofstadter takes us on wonderful walks through Godel's theorum, Escher's art and Derek Parfit's transporter thought experiment before he gets to the subject of conciousness. Those amazing Eureka! moments are where the last piece of the puzzle slots gracefully into your newly formed mental model of the world.

Mentally lazy

Obviously, some people are quite energetic mentally, to them, it's fun to listen to someone and say "Hey, you're right, if I knock a wall down here and add another window there I'll get so much more light in and have room for that chaise longue!" (some people have weird taste in thoughts). Others are not and laziness can cock a deaf ear to even the most simple idea. This is why you can be demonstrably correct and still not get someone to listen to you. This is why people get angry with you for being right sometimes, because accepting your right idea requires too much mental restructuring. Some beliefs are simply so entrenched (so foundational) as to be literally unchangeable.

Entrenched beliefs may not be as detrimental as they first sound - if my mental model is right most of the time, but you have shown me an obvious edge case where it is wrong, what is the cost / benefit of changing my entire model? Remember, all of our mental models are incomplete, their value is in how well they help us predict our future, not in how logically consistent they are. This is nicely illustrated by Philip K. Dick, who was a barking mad drug hound, yet, never the less, operated at the highest intellectual level - giving talks on reality at universities. This was because, despite believing we were still living in biblical times, 50 years after the death of Christ, his mental model made correct predictions.

When I was younger I read Richard Dawkins' The Selfish Gene and the other books in that series. They moved my mental furniture through reasoned argument and I was a big Dawkins fan for nearly 30 years. I now see him arguing from a position of complete entrenchment as a die hard atheist / materialist against equally entrenched religious people in what are supposed to be serious debates. I know he can't possibly expect to change his opponents views (my internal model refuses to shift to allow me to see him as a fool) which leaves me thinking that he supposes I am a sufficient fool to be influenced by this sham. Sigh...

People's mental models of the world are important to them and serve as the foundation of who they see themselves as. The key to being successful in changing their opinion is to help them see the benefit of shifting to your model rather than proving theirs is wrong. I guess it also makes you a nicer person to understand when being right doesn't really matter.

At the beginning

In Newton's day, it was believed that we had the fundamental equations to the universe. Knowing these equations were the key to understand everything. We could know the future of the universe simply by applying the maths. Well, we could until Heisenberg, Lorenz and Einstein muddied the waters. They showed that there were things that Newton's equations didn't account for.

We seem to be in the same Zeitgeist at the moment, where significant scientists can safely ignore evidence for phenomena which they know to be impossible. Now, this is a perfect acceptable stance if you know what's going to be discussed is impossible, or that you already have a completely plausible theory which is the only one to fit all the facts. If you are in a lift with 1 other person and you know you didn't fart, a discussion on "bottom elves" isn't going to sway your opinion on the identity of the culprit. However, the key factor here is that you are certain of your conclusion, because you believe your method of deduction to be perfect. Historically, of course, we've never been right yet.

It's important to note here that I am all for ignoring stupid people with stupid ideas. It's impossible to investigate every new idea that challenges firmly held scientific beliefs. However, you have to look at the person behind the idea. In 1970 Hannes Alfven won the Nobel prize in physics, yet he had papers rejected by technical journals on the grounds that they did not agree with current theoretical physics. I don't think I'm stretching things to say that Nobel prize winners have earned the right to disagree with the current dogma.

Science is young

I recently heard Noam Chomsky described as being a polarising figure in linguistics: is he right or wrong? That, to me, is a question based on the belief that we are so close to "finishing" linguistics that we can ask questions about being right or wrong. In a game of golf when the player is on the putting field we can make similar statements about a shot. It's a good shot if the ball goes in the hole and a bad shot if it doesn't. However, we have different definitions of a good shot from the tee, because we can't expect a hole in one every time. Now imagine teeing off in Edinburgh for a hole in London - the definition of a good shot there could be broadened all the way to "did the ball travel south?".

This is where I believe we are with science, really quite close to the start. Despite the computers and space travel, I suspect there's still a long way to go yet and this makes a big difference to the questions we should be asking and the attitude towards new ideas we should be having. I always find it helpful to remember the massive gaps in our knowledge or our total failures when faced with the dogmatic certainty of a tv presenter like Brian Cox.

• We don't know how 2 dimensional DNA encodes the complex 3 dimensional structures required for life (we're basically stuck in genetics).
• String theory (we're basically stuck in physics).
• People still die.
• Nassim Taleb can make a living explaining to financial workers that they still don't understand chance.
• Our attempts to build a robot that can walk on two legs are in their infancy.
• Despite the presence of the sun, there's an energy crisis.
• Dark matter?
• We need a singularity to explain creation.
• We don't understand what conciousness is.

Despite that last gap in our knowledge, many still believe that we are so close to understanding everything, we'll soon be able to create sentient machines. Anyone that's tried to use a printer's OCR software will know that we are still safe leaving little Timmy alone with the toaster.

Conclusion

Embrace not being all knowing and relax your expectations. This way we could comfortably praise Chomsky as having "hit the ball south" and discussing his ideas as progress along the way. To me, if Sheldrake is right about morphic resonance it's pretty much a "hole in one" scenario. The most I expect from him is to "hit the ball south" and that his experiments will be noted in history as markers along the way to some greater understanding of conciousness or reality. We are close to the beginning of science and we would progress faster if we started acting like it.

• We need a healthy, skeptical outlook without dogmatic disbelief.
• We need alternative sources of funding and a viable alternative to big science.
• Respect for scientists outside the mainstream.
• A more open scientific media.

I want off

Today is the day I lost my last remaining ounce of hope. I want it to go on record I tried with you people, I really did. I wanted this work, I wanted us to be happy, but.. we just can't. Oh and by the way, it's not me... it's you.

First, this is a thing

I found this today: literally unbelievable. It's a collection of references to The Onion articles taken as factual by the author. I just don't want to live in a world where satire has been rendered obsolete... either because people are too broken to recognise it, or because reality is too broken for people to tell the difference.

Secondly, parcel deliveries

I ordered a book to my work address, which is a company name at an industrial estate. First attempt was made to deliver on Sunday. Today, I received a text saying delivery would be attempted at some point after 5. Just after 5, I thought I would stop by reception on my way out and check if the delivery had been made. The van was parked outside and the receptionist kindly caught up with the delivery driver to ask him if he had my parcel. He stated he had one more left to deliver, for Sarah, in my office. I explained I had a text stating the delivery was due today, at which point he looked at me and said "Are you Anthony?". I confirmed that I was and he replied "Ah great, your parcel is in the van, I was going to deliver it later, so you've saved me a trip" and gave me a big grateful smile.

Thirdly, ban bossy

Ban bossy Really? I mean, seriously? All I have to do, in the opinion of Jennifer Garner, Beyonce and other such assorted ass-clowns is not call my daughter bossy in order to rear a confident, self possessed young woman brimming with self-esteem. Wow, well that's just lifted a massive burden from my shoulders, because, up until now, I'd foolishly assumed rearing a child might be a super complex task which couldn't be boiled down to a simple slogan!

I've needlessly fretted that I may have to handle each scenario based on it's own merits, with no real road map to guide me but an abiding love for my child and desire to do what was best for her in the long run (which, I'd chauvinistically thought might include teaching her when it was time to give daddy just a touch of peace and shut her noise hole). However, I now realise that it's only male children that need to be prepared for the harsh realities of life by learning to curb their natural self obsession in order to become more rounded and caring individuals in the future. Girls on the other hand, need to be encouraged towards narcissism so that one day they'll have the self confidence to stand in front of a camera and say, with a straight face, "I'm not bossy, I'm the boss". Imagine your pride as you turn to the person next to you and announce "That megalomaniac douche burger is my daughter".

Previously, I had failed to realise how powerful a word bossy is. As Anna Maria Chavez tells us "When I was growing up, I was called bossy" and we can see that she's turned out to be a complete idiot, so... case closed, lets ban the word bossy. The powerful info-graphics make the case even more air tight by claiming "Between elementary and high school, girls’
self–esteem drops 3.5 times more than boys’.", obviously with a statement that powerful, you don't need to cite the study involved, it's just a fact! The correlation between a self reflective property measured in juveniles and the use of the offensive word being self evident and thus requiring no proof.

I shall be spending all my resources on finding a way off this planet and leaving you to it.

Considered harmful: rockstar developers

Ten years ago when I told people that I worked with computers I would often get the response "you don't look like a geek". These days no one seems to think it strange. I currently work in an office in which some of the developers talk about football and have meaningful social relationships. Being a software engineer has become somewhat cooler; as part of that "coolification" process, certain things have changed and other things, which always existed, have been named and magnified. Rockstar developers have always been a thing, but now they have a name and are often seen as desirable. Before I start to explain why I think rockstar developers are harmful, lets define one and the circumstances in which they are harmful.

Characteristics

• Above average understanding of their language.
• Love of esoteric knowledge.
• Egotistical style of programming.

The first two items on the list aren't in any way negative, however, they can lead to problems if not applied responsibly with reference to the environment they are used in. It's the third characteristic that I believe leads to harmful behaviour, because the "me, me, me" can overrule common sense when it comes to the application of logic in a given environment. So there is a tendency to create overly complex solutions to simple problems as small monuments to personal vanity.

Habitat

If you are a rockstar developer as described above, working on a solo project, then go ahead, knock yourself out. It's like being a singles tennis player, there's no need to alter your style for the benefit of others. Have fun, it's your code.

If you are working in a commercial environment, being paid to do a job, then it's not your code. If you are working with a small team of like-minded rockstars, then I hope it's the nirvana it should be and once again, have fun! Unfortunately, the likelihood is that you are working as part of a team of individuals of mixed ability. This, to me, is where rockstars become harmful. It's almost always a problem related to the egotistical programming style creating problems for others. If you are part of a team, then you need to act like it and put the needs of others above your own need to show off.

Obfustication

Yea, sure, bitwise operators are interesting and using them can be a shining badge of your elite status, I mean, how else will people know you can use them unless you do? In a large team, with high code churn, it's pretty likely that someone else will have to read / understand and then modify your code. If you have code reviews, then it's a certainty. Here's an illustration with some reasons why obfustication is awesome and my rebuttals. It's not a real conversation as I wouldn't change someone's code without talking to them first.

"Hey broheim, I was checking the logs and saw you changed my code dude, what's up with that man? It's like, you took my gnarly code, babyfied it. You know your code doesn't do the same thing right?"

"Yup, it's more readable now and therefore maintainable by all members of the team, so I figured it was worth changing. I understand that your code is checking purely for -1, but that's a different discussion."

• Original code: if (!~index) index = 0
• New Code: index = index < 0 ? 0 : index;
• The new code is a conditional ternary operator which is used quite widely in the codebase, if it wasn't, I'd have written:
  

  if (index < 0){
      index = 0;
  }

Here are the most common reasons I've heard as to why something like the original code is better. In my rebuttals my arguments are designed to be for the general case of unnecessarily complex code while still referring to the specific example.

It's not my fault everyone else is an idiot.

Although I've put this point in it's harshest possible form, this is the point I feel has the most value. Finding code you don't understand and looking it up is a very valuable way of learning. In this case though, I'd argue that it's not the right code in the right place, it's just a block of vanity code. Even though you understand that the ~ operator switches the 0's and 1's around in the binary representation of the operand, it still isn't immediately obvious that the code is checking for the case where index is equal to -1. There are enough complex things which require complex solutions, lets leave simple things as simple. It's also hopelessly naive to assume that people will understand unnecessary complexity just because they should. It's like leaving your wallet in your unlocked car because no-one should steal it.

Optimisation dude!

Ok, this is a blog post all on it's own, so we'll gloss a little here. Lets just say that there are two forms of optimisation that are important in a commercial environment.

Code Optimisation

Most important point: optimise where it hurts. Looking at the performance difference in time between our different approaches is all well and good, but we need to take into account the environment in which we are working. At the end of this code, we then append the result to the DOM. Optimising a conditional in this environment is like optimising your drive from Glasgow to London by running to the car (perf. test).

Maintenance optimisation

In general it is much easier to show the cost to a company in lost man hours caused by hard to maintain code than it is to show the boost in profits caused by pre-optimised code (I'm referring here to code optimised by a developer prior to any requirement from the customer). So it's usually preferable to write maintainable code first and then optimise where it's hurting.

Complexity is better

I know this may sound strange, but I have first hand experience of a culture in which a complex solution to a problem was considered better by virtue of it being more complex. After a long discussion of the differences between two possible solutions, it was finally agreed that both solutions achieved the same goal. One group insisted that the more complex solution was better "if you are a developer", yet were unable to define a single benefit of the complex solution over the simpler one. I have also been told, as a put down, "yes, I understand your proposal, it's so simple even my grandmother could understand it". Despite how crazy this sounds, it's actually an easy trap to fall into. If something has been hard to work through, it can be difficult to accept that there is an easy solution, you want it to be difficult and require a complex solution to justify the time it took you. Again, beware of your ego.

Conclusion

Coding is interesting and those of us who do it for a living are lucky, we get paid to do fun stuff. Being good at coding is something you want to show off, but like many things it's not the flashy stuff that shows your mastery. A complex piece of work, that is simple to read and understand is the sign of great coder. The good thing about this attitude is that it scales. What you think is easy to read depends on your level of competence, to someone less experienced there may be logical tricks you've used that they have trouble following. This is where they will learn from reading your code, but without the unnecessary obfustication we've been discussing.

Code reviews

I have been doing a lot of code reviews recently. Obviously, criticising someone else's work in a constructive manner can be a tough skill to acquire, conversely, I also used to feel quite patronising making positive comments. After a while though, I think you hit your stride and develop your own style of commenting. It quickly becomes pretty obvious that you need to have a clear idea in your own head of what you are trying to achieve with your code reviews. When you start to think about what you want to achieve, you realise how much value you can get from code reviews. Yes, they are time consuming, but consistent reviewing can really add a lot of value.

• Checking for security vulnerabilities
• Sense checking for possible bugs
• Enforcing the agreed architecture of the project
• General code quality
• Enforcing code standards
• Training

That's a list of what we've been trying to get out of our code reviews. Because they have to be consistent, it really helped having a clear idea of what we were looking for and what our definition of "good enough" was. In a commercial environment, it's important to make only those changes with a business case and not use code reviews as an excuse to endlessly polish. Thinking "hmmm, I wouldn't have done it like this" isn't reason enough to change someone else's work, you need to refer back to your list and see if there is an actual reason. I found this the most difficult part of learning to give code reviews. I often felt strange glossing over blocks of code I didn't feel were particularly well written because they were "good enough" while commenting on jsDoc, line spacing or naming conventions which didn't meet coding standards.

Finding your voice

Through trial and error I found that asking questions rather than making statements is a good way of introducing training into code reviews. When I spot something I don't like I often ask questions around the area. It's amazing how often forcing someone to articulate what they are trying to achieve creates a eureka moment. It suddenly becomes obvious what is wrong when you notice a series of function names don't correspond to the language you are using to define the problem.

It also took me a while to realise that I didn't have to know the answer to everything in order to be eligible to do code reviews. I know that's one of the points of peer review, but it's difficult to keep that in your head when you are reviewing. I like a conversational tone in a code review to help alleviate the idea of being judged or being confrontational. I also think that it helps make the process two way. If you tell someone to check for a valid user name, they will likely just implement what you've asked for (you, who haven't been working on the code for the last 2 weeks). However, if you ask what happens when there isn't a valid user name you get input from the person who wrote the code.

At the risk of over stressing this point, you don't have to have a brilliant solution for every comment you raise. "Hmmm, something in this just doesn't sit well with me, but I am not sure what. What do you think?". Is a perfectly acceptable comment, especially if the developer comes back with the solution you failed to think of.

Oddities

Strangely, it's much easier to criticise good code than bad. Good code is easy to read and understand which makes it much easier to think of improvements. With bad code you struggle through the logic, it's difficult to understand what it does and more importantly what it's meant to do. Finding the pivot points in which you can start to improve the code is hard work and there's so much more you have to say. This is also the time when you have to be careful how your comments come across. "I would expect a function called isValid to return a boolean, not mutate the value" is making a reasonable point, but what the developer will probably read is "You are a terrible person, that is why I hate you and your ugly code" which may not have the desired effect. In cases of really bad code, I tend to avoid the review and just help the developer re-work the code in person.

Conclusion

Spending a lot of time reading other people's code may initially seem like a cruel and unusual punishment and depending on the code it really can be. Code reviews can be super time consuming if they are on a section of the code base that you aren't familiar with. However, by the end of the review, you know the code base better and you will have levelled up your "reading other people's code" skill.

Code reviews have helped us keep the quality of the code base higher than previously. It also saves us time in bug fixing by enforcing better unit tests. We also have a level of consistency running through the projects now in terms of coding standards and architecture which is really nice. It certainly makes future development faster when developers come to work on a new project and find it fundamentally works in the same way as all of the others. I can't honestly say code reviews are a fun part of my day, but the results are too useful to ignore.

Banning things is awesome

I wrote recently that I don't think banning things is a cost effective way for governments to solve problems. The first reason for this is simple: supply and demand; the second reason is that it's rare that something bannable is actually the root cause of the problem; finally, banning things is a restriction of personal freedoms and those should never be given up lightly.

Supply and demand

If there is a demand for a thing, banning it has, historically, created a black market supply. Banning drugs is an awesome example of this, in 2010 it was reported that every bank note in the UK was contaminated with cocaine within weeks of issue. The cost of drug prohibition enforcement in the UK is estimated at £16 Billion. I'm not suggesting that the government wouldn't squander that cash on something equally useless if drugs were legalised, just that banning things doesn't seem to work. Here's a list of other things that have been banned at one time or another:

• Christianity
• Drugs
• Alcohol
• Guns
• Homosexuality
• Books
• Furbies
• Video games (Greece)

Now here's a list of things which (to my knowledge) have been banned effectively:

• Time travel (China)

Solving the wrong problem

It's easy to see why some people don't like guns, drugs or Christianity, but if banning them is expensive and seemingly ineffective, why is it such a popular choice? My guess is that it's a lot easier to ban something than it is to solve the actual issue. For example, where would you rather live, in a place where everyone had guns but no-one got shot, or a place where no-one had guns, but your neighbour dreamt every night of shooting you using your own ass as a silencer? It's quite possible that solving the issue of people wanting to kill each other might give better results than simply taking away one of the more effective ways of doing it. However, that's a difficult problem to solve, it's hard enough catching murderers after they've killed someone, let along before...

It's often easier to be seen to be doing something than it is to actually do something. Like when a friend wants to tell you about their problems. You could sit, listen, perhaps make some insightful comments, help them get their heads into a better place. But that's an evening you are never getting back, plus it sets a dangerous precedent. So, you take them out and get them drunk instead, it's way more fun for you and much less work. I think it's the same with drugs, it's much easier to be seen to create jobs for drug enforcement officers and pledge someone else's money to a cause than to actually try to reduce the demand for narcotics. Especially in the instances where drugs are not taken recreationally, but as an escape from appalling social conditions.

Liberty

In addition to not working, banning things is a reduction in personal freedom. There would have to be a lot of evidence of the efficiency of such a move to warrant it in my eyes. This is true regardless of whether I want to make use of that particular freedom or not. I didn't own a gun when they were legal in the U.K. nor do I base my sexuality on the legality of homosexuality. The point is the loss of personal freedoms to a government that is doing the political equivalent of sweeping mental health issues under the rug of gun control and shoving the mess of social problems into the closet of drug prohibition.

Don't worry, I'm not going to go into the tired old chat about banning one thing being a slippery slope to a totalitarian state. It just irritates me because it's lazy and not the fun type of lazy like someone getting their food delivered from a restaurant so close I can shout my order to them. It's the evil sort of lazy that encourages stupidity by pandering to it. It's easier to ban someone from t.v. for the words they use than explain that it's the meaning behind words that matters. It's easier to ban websites than to monitor your child's internet activity. It's easier to ban jam on aeroplanes than to make them safer. It's easier to ban certain breeds of dogs than to ensure the owners aren't idiots. It's easier, it's ineffective and it makes the world just a little duller.