Coding Standards
1. Avoid the double back flip with a half twist into the Excel workbook. Link
2. Goal is “Never touched by human hands.”
3. Have a version control system.
4. Use table driven versus code driven parameters.
5. Programs should run without errors and warnings.
6. As long as possible, tables should be vertical not horizontal.
7. Don’t repeat yourself.
8. Don’t say the same thing more than one time.
9. If your code looks like 19th century wall paper something has gone wrong.
10. Don’t say the same thing more than one time.
11. Do the work in the tool (aggregations should be on the database side).
12. Everyone on the team should be expected to understand the tools/techniques being used (e.g. Don’t code with a tool no one else knows).
13. Human time is more expensive than computer time. If processing length is not an issue, use full names for where clauses at the cost of not using an indexed field.
14. Carefully use common libraries for items that need to standardization. Discuss as a group if items should be centralized or decentralized.
Documentation
1. All documentation is wrong.
2. Technical documentation != Customer documentation.
3. The goal is to create programming that is human readable. (see Literate Programming)
Presentation
1. Reduce Ink to information ratio (Tufte).
2. Separate the data layer from the presentation layer.
3. Variance, not just point estimates (G. King).
4. Include a comparison (time, benchmarks, location, provider).
5. Some people are color blind.
6. Sans serf for computer presentation.
7. Small multiples (Tufte).
8. Include phone number, contact information, and last revision date on every deliverable.
9. Sequential versus Categorical variable should have different color schemes.
10. Alphabetical best is not order the.
11. Control the paper – people want to look up their own score and stop listening.
12. Don’t write a mystery novel.
Tools
1. A $1,000 golf club will not make me a professional golfer.
2. Excel is the most widely used BI tool in the world.
3. The benefits of common tools likely outweigh the benefits of a specific tool for a specific situation.
4. Learn how to use the tools you have been given to the maximum extent possible, instead of jumping to learn the next cool thing.
5. “I don’t think I own a pen.” (Teera Price, 7/24/2012)
Analytics versus Reporting
1. What happened versus why?
2. Statistics are a form of evidence to support an argument.
3. p < .05 does not mean something is important.
4. What is the unit of analysis?
5. Data -> Information -> Knowledge -> Wisdom
Quality Assurance Processes
1. Quality Assurance is a set of processes, not a binary variable.
2. QA done by someone other than who wrote the program.
3. Define acceptance criteria prior to starting to develop (test driven development).
4. Pair programming.
5. Develop separate QA programs to monitor ongoing processes.
6. Computers are good at adding. Most QA problems in reporting is a mismatch between what someone thinks is the definition and what the definition actually is.
7. An error that is not reproducible is almost impossible to diagnose. The phrase “This report is wrong” is noise.
Personal Development
1. Spend at least 2 hours per week learning new things.
2. “zone of proximal development” (Vygotsky)
Data Structures
1. A reporting environment shouldn’t be in Third Normal Form. Multiple joins make things difficult.
2. Separate the transaction and the reporting environments.
3. The definitions of the metric should be stored in the database.
4. Data is a corporate asset. It shouldn't be owned by an individual person.
Project Management
see: Pinnacle Projects
1. Reduce Work in Progress
a. More people working on fewer projects
b. Avoid big up front requirements
2. Agile with scrum
a. One and only one product owner, many stakeholders
b. Daily stand-ups, sprint planning, sprint retrospective
c. About 10% of the team’s time should be spent in planning
d. Time box deliverables (every 2 weeks).
e. Deliver incremental improvements that add value to customers.
i. “Small, meaningful pieces”
f. Once commit, no new items added until 2 week commitment list is completed.
g. Team review of actual deliverables (not Power point summaries)
h. The ideal team size is 7 people +/- 2
3. Excellent people develop reproducible processes
a. We don’t want the assumption to be “This is correct because XXX person did it.”
4. Reporting costs money. What is the cost per week for your team? Are you supplying that much value to the company?
Client Engagement
1. Never promise something that you personally can’t deliver (for individual contributors).
2. Don’t skip the understanding of the question and move directly to the technical requirements. What problem are you going to solve? Understand the data generation process.
3. What action will be taken as a result of this information? If the numbers are poor who is going to be held accountable?
4. Metrics are a reflection of an underlying process.
5. Accurately estimate (as opposed to Under promise, over deliver)
6. We not I