There is a problem within the developer community which I have alluded to in the past on Twitter and other social media sites. The problem is misinformation. Information is arguably the most powerful force currently in the world. Those who are new to sharing information often do not realize the power that they wield.

We tend to take written information as truth and assume it is accurate unless we know for certain that it is not. If we read something about a subject which we are not very knowledgeable about, we assume that the author has the credentials to be posting that information. Otherwise, why would it be posted?

As developers, we are frequently using the internet to help us solve issues. We run across an error code, a crash, or another type of problem and we usually go to the internet. With the vast amount of knowledge that is available, and the incredible search engines that we have at our disposal, it is pretty easy to find someone else who has already run across the issue. Sites like StackOverflow make it even easier to find other people who have experienced the issue we are running across.

The issue is that we don’t really know if the information being shared with us is accurate. The author of that post, or response, may be guessing. They may have found a hack or workaround that kind of works, for now. They may be completely wrong and are treating a symptom as the actual problem.

Even information from the creator of the code we are using might be completely wrong.

What’s even worse is that information gets passed around like a bad version of the telephone game. Soon it has a life of its own that is forever a part of our developer culture. That information is passed on and becomes a rule.

You should see some of the insanity I have heard because someone once said “goto is evil”¹.

In the years that I have been working with Core Data, and attempting to help other developers, I have run across a number of these situations. I try and find the source of the information and get the author to update their blog post and StackOverflow answer to correct the information in an attempt to reverse the danger. It doesn’t always work.

A case in point is a blog post written by Brent Simmons a number of years ago. In that post, he described a situation that was extremely unique to him. A situation that is unusual enough that even calling it an edge case would give it too much credit. In his post, he detailed the issue and explained why Core Data did not work for him. He went on to say that it was a unique situation and that his situation should not prevent others from using the framework. He even stated very clearly that he liked the framework, will use it in other situations, etc.

What message got passed on? That Core Data has a gaping hole and that it should be avoided.

To this day, there will be at least one conference a year where someone will walk up to me and say, “So about that blog post that Brent wrote…”

There are a lot of others just like it. Authors almost never have malintent, but are actually trying to help. Their message either gets lost or misinterpreted. Sometimes the author really believes that they are providing a service and that the framework is truly broken — when in fact it is their lack of understanding that is at fault.

So what can we do?

If You Have Nothing Good To Say

The first thing we should do, as responsible people who have the willingness to share information is to ask ourselves, should this information be shared?

I am not suggesting hiding bad information. That doesn’t really help either.

Look at the light in which you are presenting the information. Are you presenting the information as fact or supposition? Are you describing a problem that you are having or are you describing a problem that the library is having? These are not the same thing.

When you write an article in a voice that describes the library as having a problem, you are most likely doing a disservice to the library and to the community.

Yes, that is a bold statement.

Negative information doesn’t really help anyone. At best it will be misunderstood, and at worst it is link bait. Just a way to get attention and hopefully make a name for yourself.

Everyone wants to be popular, but that is the worst way to get it.

Dare To Be Wrong

Instead of shouting from the rooftop that the library has a problem, you need to change the voice. Describe how you are having an issue with the library, and present it with the very real possibility that you are wrong. Talk about how you approached the problem and how you investigated it. Talk about what your assumptions are and the issues you have run into.

It is the same information as blaming the library for being faulty, but framing the voice to admit that you may be wrong.

That is powerful. That is the boldest statement you can make. Stand up and say to the world: “I was unable to solve this, but this is what I found”.

You will be amazed at the difference in the response that you will receive.

Provide Facts, Not Supposition

If you are going to write a piece about a problem you are having, provide a test case.

Science, in all of its forms, is worthless without repeatable evidence.

If you are going to post a piece about an issue you are having, isolate it in a test and provide the test. This will do many things:

1. Those who have knowledge but don’t have the time to try and recreate your experiment are far more likely to investigate the issue you are having. I personally skip over many questions that I cannot easily reproduce. If I need to spend two hours or more to try and get the same results as you, I am not going to do it. Sorry, but you just lost someone who may be able to help you.

2. In developing your test case, you may discover the problem. I cannot count the number of times that I was certain there was an issue with a framework or library, and in building the test case the problem went away. If the problem cannot be reproduced in a test case, then the problem is not where you think it is. The problem is somewhere else, which means your original supposition was wrong. You just saved yourself pain and you learned. Nothing is sweeter.

3. If it is indeed an actual problem, you are now prepared to send all the information to the author of the library. Apple will rarely look at an issue unless there is a test case associated with it. Skip the middle step and provide them with the test case right away. Providing those test cases is incredibly valuable. I simply cannot stress that enough. Your test case may provide the information that the author needs to solve the issue, even if you are the thousandth person to file an issue. The other 999 may not have given a succinct enough test case. You never know.

If you are writing an article that is talking about a problem, it is morally imperative that you supply a test case. If you do not, you are most likely spreading misinformation. Congratulations, you are now part of the problem. The future will not thank you.

If you are afraid of being wrong, afraid of being embarrassed, and therefore refuse to supply a test case, do everyone a favor and do not write the article.

Do Not Skimp On Details

I do not know about you, but I have a habit of assuming other people know what I know. At least when it comes to basic things like error handling, etc. That is a bad habit of mine that I implore you not to replicate.

Far too often I see test code like this:

NSArray *array = [[moc executeFetchRequest:request error:nil]];

It is just shorthand, right? Everyone knows that in production code you need to capture that error and handle it properly, right?

Nope.

In far too many cases, I have solved a problem for a developer (who was kind enough to send me a test case) by simply capturing the error and reporting on it. Five minutes of my time, but hours of theirs.

Lazy? Maybe.

Most likely they saw the nil being passed in on some example and copied the habit. They might even think it is the correct way to do it.

Please do not contribute to that type of misinformation. Make the code succinct, yet complete.

The Damage You Do

A couple of years ago I was answering questions on StackOverflow and I noticed a reoccurring problem. A large number of developers were doing something very strange, and all doing it the exact same way.

I was seeing this repeatedly:

NSManagedObjectContext *moc = [self managedObjectContext];
NSFetchRequest *request = [[NSFetchRequest alloc] init];
[request setEntity:[NSEntityDescription entityWithName:@"Person" inManagedObjectContext:moc]];

NSError *error = nil;
NSMutableArray *array = [[moc executeFetchRequest:request error:&error] mutableCopy];

It was far too consistent to be a coincidence. So I researched it to see if I could find the source, and eventually I did. Someone had written a book about Core Data, and in one of their introductory chapters they had used this code.

Why? My guess is that they were trying to teach about fetching on iOS without having to introduce the NSFetchedResultsController yet. Therefore they were just fetching and holding onto the array. From there (again, my guess) they needed to demonstrate how to remove things from a UITableView and they just made the array mutable.

Harmless? I’m sure they thought so.

Most of the StackOverflow questions were of the nature of:

• I removed the item from my array but it showed up on next launch.
• How do I delete from the database?
• How do I refresh data in this table view when another view creates data?

And the list went on and on.

Reasonable questions but they all had a core issue. They thought the NSMutableArray was somehow tied to Core Data and that manipulating the array would change things in the persistent store.

A simple thing in sample code and it caused a significant ripple through the community.

Being written in a book made it even worse. It was not only written, but it was printed. Things that are printed are fact checked and guaranteed to be accurate, right? If you are reading the book for information, you need to assume so and you would not really know if it was accurate until it was too late.

Be Helpful, Not Harmful

As with nearly everything I write, I write after I have already stepped into the trap myself. This article is no different. If you look around CIMGF you will find at least one post written by me that is wrong. Hopefully you will also now find at the top of that post a disclaimer like this:

The author of this post was wrong. This information is either out of date or incorrect. Do not use this post as a guideline. The post is remaining on here for historical purposes.

If you just delete the post then the search engines will only have a cache of the misinformation and it will live on. If you leave the post but put a disclaimer in it, or correct it, then there is a chance you can undo what damage you might have done.

The internet is an incredible wealth of knowledge. The really cool thing is that you can contribute to that knowledge. You can help to improve mankind. Your voice is extremely powerful.

Use it for good.