The most common metrics for measuring the complexity (or simplicity, if you take simplicity to be the opposite of complexity) are McCabe's Cyclomatic Complexity and the Halstead Complexity Metrics.
Cyclomatic complexity measures the number of distinct paths through a given unit, usually a method or function, although it can also be computed on a class. As the number of paths increase, it becomes more difficult to remember the flow of data through a given module, which is related to the concept of working memory. High cyclomatic complexity tends to indicate difficulty in the ability to test a module - more test cases are required to cover the various paths through the system. There have also been studies that have linked high cyclomatic complexity to high defect rates. Typically, a cyclomatic complexity of 10 indicates that a unit should be reviewed and possibly refactored.
The Halstead complexity measures use the inputs of total and distinct operators and operands to compute the volume, difficulty, and effort of a piece of code. Difficulty, which is the (number of unique operators / 2) * (total number of operands / number of unique operands), is tied to the ability to read and understand the code for tasks such as learning the system or performing a code review. Again, you can count this on a system level, a class level, or a method/function level. There are a few postings about computing these measurements here and here.
Simply counting lines of code can also give you an idea of complexity. More lines of code means that there is more to read and understand in a module. I would be hesitant to use this as a stand-alone measurement. Instead, I'd use it with other measurements, such as number of defects in a given module to obtain defect density. A high defect density could indicate problems in writing tests and performing code reviews, which may or may not be caused by complex code.
Fan-in and fan-out are two other metrics, related to the flow of data. As defined here, fan in is the sum of the procedures called, parameters read, and global variables read and fan out is the sum of procedures that call a given procedure, parameters written to (exposed to outside users, passed in by reference), and global variables written to. Again, high fan-in and fan-out might be indicative of a module that might be difficult to understand.
In specific paradigms, there might be other measures or metrics that are also useful. For example, in the object-oriented world, monitoring coupling (desire low), cohesion (desire high), and depth of inheritance (desire low) can be used to assess how simple or complicated a system is.
Of course, it's important to realize that a lot of measures and metrics are simply indicators. You need to use your judgement to determine if it's necessary to refactor to increase simplicity or if it's not worth the effort to do so. You can make the measurements, compute the metrics, and learn about your code, but you don't want to design your system by the numbers. Ultimately, do what makes sense.