When you're building things for the huge audience the Web allows, a very real fear that you have is a software glitch that prevents data from displaying correctly. When developing projects on a tight timeline, testing is an aspect that often gets neglected as the deadline gets closer and closer, and often things need to be viewed by other people (editors, managers, and the like) even earlier, emphasizing output over process in turn. Let me be clear--if you want to ensure that your visualizations are high-quality, you need to take steps to ensure that they are well-tested and functioning properly. On some level, doing this is an exercise in managing complexity.

The following chart depicts project complexity over time. As you can see, complexity increases somewhat exponentially as time goes on. Adding more team members, more lines of code, and/or more dependencies increases the project's complexity dramatically. Meanwhile, the step-chart depicts how tooling processes improve in response to complexity--although it's possible to implement all of these at the beginning of every project, often it's better to do so incrementally in response to the project's demands. For instance, generally everyone will start with version control because it helps collaboration, can revert mistakes, and provides a project with history (plus, it's really easy to get set up). Then, say, you add a few more team members or open-source a project. Now, you have code flying at you from all angles; having some way to automatically test whether a change will break anything starts to become incredibly useful. A bit later, imagine that a lot of bad code is still getting past the automated testing; having manual code reviews might further help.
Each of these improvements to process takes time to both implement and use, and whether they'll benefit your project is hugely dependent upon how big your team is and how well you trust every member of it (or, if you are working alone, how well you trust yourself not to introduce errors):

The preceding chart is from Martin Probst and Alex Eagle's talk on TypeScript at AngularConnect 2015. They touch on a lot of the same topics as this chapter and it's worth watching; you can find it at https://www.youtube.com/watch?v=yy4c0hzNXKw.

In this chapter, we'll focus on a few technologies to help manage project complexity:

• We start by talking about linting. Linting is when you run your code against preset rules to ensure that it conforms to a set of standards.
• We then move to static type checking, which is a tool to ensure that you're correctly passing the right kinds of variable between functions at build time.
• Automated testing is what it says on the tin; you write tests for your code, all of which it must pass. Failing tests can be used to diagnose bugs or other issues with the code.

The aforementioned tools all try to do two things -- help reduce bug density and improve the development experience. Primarily, they accomplish this by providing feedback to developers while coding, ensuring that things such as misspelled variable names or incorrectly passed arguments are caught in development instead of in production.