It often feels like accuracy should be the most important thing when conveying information. Why wouldn’t it be? What’s the point of explaining something that’s false? Whether we are writing a blog post, documentation, a book, or anything that someone else will read, we want to make sure what we are saying is true.
But being 100% accurate is not always the most important thing. I would argue that settling for 80-90% accuracy can be ok if it helps make things significantly clearer. Let’s look at Wikipedia for example. Multiple studies have shown that the accuracy of the science/technical articles on Wikipedia are ~97% accurate. Sounds great right?
Have you ever learned something technical from Wikipedia with no previous knowledge on the subject?
Take a look at the entry for Database:
A database is an organized collection of data.[1] It is the collection of schemas, tables, queries, reports, views, and other objects. The data are typically organized to model aspects of reality in a way that supports processes requiring information, such as modelling the availability of rooms in hotels in a way that supports finding a hotel with vacancies.
A database management system (DBMS) is a computer software application that interacts with the user, other applications, and the database itself to capture and analyze data. A general-purpose DBMS is designed to allow the definition, creation, querying, update, and administration of databases. Well-known DBMSs include MySQL, PostgreSQL, MongoDB, MariaDB, Microsoft SQL Server, Oracle, Sybase, SAP HANA, MemSQL and IBM DB2. A database is not generally portable across different DBMSs, but different DBMS can interoperate by using standards such as SQL and ODBC or JDBC to allow a single application to work with more than one DBMS. Database management systems are often classified according to the database model that they support; the most popular database systems since the 1980s have all supported the relational model as represented by the SQL language.[disputed – discuss] Sometimes a DBMS is loosely referred to as a “database”.
Database, en.wikipedia.org/w/index.php?title=Database&oldid=782511180 (last visited May 27, 2017).
This is accurate and would make sense to someone with a background in software development. It is also pretty useless to someone without that background. Despite its accuracy, it effectively provides no information to these folks because it isn’t accessible to them.
Wikipedia is a great reference so it makes sense that their goal is to be as accurate as possible. However, something that is meant to be more introductory should have the goal of being clear, even if that means it will be less accurate.
I tend to describe databases as giant spreadsheets. Is it accurate? Not quite. The analogy doesn’t account for SQL vs NoSQL. It doesn’t account for indexes. It doesn’t account for join queries. It doesn’t account for many other things.
But most people have dealt with spreadsheets at some point in their life. That gives them a visual representation of what data in a database could look like. Being able to visualize something makes it much easier to understand something. It serves as a foundation for further learning, even when that includes corrections to the inaccuracies of that initial visualization.
Let’s use a different example. Let’s look at a drawing. 
Artists usually don’t start drawing from the top down, pixel by pixel.
They start with sketches. This sketch provides an idea of what the whole thing should look like. It serves as the foundation. It is just a sketch though so there are a number of inaccuracies, even if you ignore the lack of color. Those can be corrected after the sketch is complete.
That’s not to say that accuracy is irrelevant. I mentioned trading in some accuracy for clarity. Trying to describe a database with the image of a squirrel is completely worthless.
The image is clear, but it doesn’t convey any of the information that’s needed to understand what a database is.
Like many things, there is a balance that needs to be reached. We want to convey useful information. That means that it does need to be somewhat accurate, but it also means taking opportunities to make things clearer. Trading a little bit of accuracy for a lot of clarity can make information exponentially more useful to people. That trade is well worth it.
This post was originally published on blog.professorbeekums.com
Top comments (2)
That's a good thought and reminds me of an interview I once had. The interview was for a technical position but one of the people interviewing me was totally non-technical. At some point, I had referenced github a few times -- and the person finally threw her hands up and said "I need to ask you a dumb question. I hear people talk about github all the time but I have no idea what it is. Can you please explain it to me?"
I asked her if she knew what version control meant and when she said no, the best I could do was say 'github is google drive for developers. it lets you keep all previous versions of code and collaborate with others.'
That's a really good way to describe github. Google's office products have been a boon for me when coming up with descriptions. I use it to describe concurrency a lot :)