Inspired by Tim Wilson’s list – I took a developer viewpoint to create my own.
In no particular order:
- Anything that includes ‘with a single line of JavaScript’ in the marketing material likely isn’t being fully honest.
- Analytic implementations can break without notice.
- Analytic implementations can break and it’s no one’s fault.
- Data Loss happens and can’t always be prevented.
- You should have a data recovery plan.
- You should have a disaster recovery plan.
- The more systems you link together, the greater the chance something will fail to work as expected.
- There is a real cost associated with Big Data in terms of storage and querying.
- Cloud tech solves problems – and introduces new ones.
- Microservice designs solve problems – and introduce new ones.
- Monolith designs solve problems – and introduce new ones.
- Not everything needs to be tracked.
- Security assessments matter.
- PCI-DSS, HIPPA, etc – may apply and are not optional when they do.
- Anything dealing with the concept of time is likely to be buggy on release.
- Any bugs related to the concept of time are likely to be difficult to find.
- Any bugs related to the concept of time are likely difficult to explain.
- Anything dealing with the concept of location is likely to be buggy on release.
- IP Address lookups and GPS lookups are less accurate than you might think.
- Remarketing is likely on its way out.
- The marketing tech stack will change dramatically over the next few years due to privacy issues.
- Any work involving privacy laws is going to take longer and be more difficult than anyone expects.
- Analytics and Data Governance are operational costs, not capital.
- People often adopt personalization without fully understanding the implications to their staffing or processes.
- A/B testing is mostly technically straightforward, designing multiple viable user experiences is hard.
- The design of the database you are storing data in matters.
- You can never trust the user’s browser
- Comparing data between different systems is often a rabbit hole from which few emerge.
- Not every page needs to be a Single Page Application.
- Not every problem should be solved with (insert language here).
- You should have automated testing.
- Deployments don’t happen on Fridays, before holidays etc – unless you have 24/7 Dev Op support.
- Deployments should happen during the period of lowest user activity when possible.
- Continuous Deployment should be something to strive for.
- A feature isn’t complete if the analytics don’t function properly.
- Tags can have a performance impact to site speed.
- Page Performance matters.
- Almost any tool you install will need custom configuration for your site.
- Most development training does not cover analytics, privacy or tagging.
- Systems can count differently on a fundamental level.
- The same term can have different definitions across platforms.
- All data should be validated on the server.
- The system should assume that anything sourced from the client may be missing, wrong, or harmful.
- That the closer to real time you want something, the more it’ll cost.
- That the closer to real time you want something, the more difficult it will be to design.
- The priority is fixing a broken build.
- A.I. solves some problems – and introduces new ones.
- Machine Learning solves some problems – and introduces new ones.
- Getting consistent behavior on multiple form factors, browsers and rendering engines isn’t trivial and is sometimes impossible.
- Version Control isn’t optional.
This post is a mirror of my LinkedIn article.