Upgrade to the Modern Data Stack

 

Solution: The Modern Data Stack

There's already a tool perfectly suited to storing massive amounts of data, that can be queried easily, and is connected to everything. A database or data warehouse. You probably already have one running in your company that you can reuse so you don't need to buy another CRM, CDP, DMP, MAP, or any other acronym.

Building around a data warehouse has additional benefits such as:

• You own your data. It helps you comply with different regulations.
• Get value quicker. It is 10x easier to dump historical data in a DB than importing the data in yet-another-tool.
• Easier to sync with other tools. Databases integrate with everything, contrary to SaaS Tools that have limited APIs (and please don't get me started on APIs like Marketo).
• Reusability. Other teams in the company can use this trusted source of truth.

In addition to a data warehouse, you will need 4 other key components:

1. An event tracking tool. You can continue using Segment here. It does the job well and allows you to collect events across all of your websites & apps.
2. A data loader. I recommend Fivetran. It’s easy to set up in a couple of clicks and amazingly reliable.
3. A data modeling tool. DBT is the new power tool here. It allows you to transform and model your data.
4. An Integration Platform. I’m a 100% biased here, but I recommend using Census. We integrate well with DBT and enable you to sync your clean and unified data models back to all of your other tools.

As a bonus, you can replace Amplitude with a BI tool like Mode or Chart.io, which is cheap and as good as Looker.

Reference: https://www.getcensus.com/blog/graduating-to-the-modern-data-stack-for-startups

A few cheat codes and tips from experienced Software Architects

 Having clean software architecture and staying conform to pre-defined design principles from start of the project is one of the best ways to avoid possible technical debt in the future of that software system. Clean Software Design is a key point for an effective software product.

Let us have a look at some important principles, rules, guidelines that ensure a clean software design:

Principles:

1. Loose Coupling — if classes use each other, they are coupled together. The less classes are coupled, the easier is to change them.
2. High Cohesion — degree to which elements of a whole belong together. Components of the class should be highly cohesive.
3. Locality — Changes, maintenance, extensions are only local. This leads to no harming whole environment.
4. Removeable — Software Components should be easily removeable.
5. Small Components — software system should be only of small components ideally each doing only one task.

Class Design:

1. Single Responsibility Principle (SRP) — class should do only one task.
2. Open Closed Principle (OCP) — class should be extended not modified.
3. Liskov Substitution Principle (LSP) — child classes must be able to replace their super classes.
4. Dependency Inversion Principle (DIP) — dependeny is reversed: high level components are free of low-level components.
5. Interface Segregation Principle (ISP) — interfaces should be small: classes should not implement unnecessary methods.

Cohesion Principles:

1. Release Reuse Equivalency Principle (RREP) — only together releaseable components should be bundled together.
2. Common Closure Principle (CCP) — classes that change together should be bundled together.
3. Common Reuse Principle (CRP) — classes that are used together should be bundled together.

Coupling Principles:

1. Acyclic Dependencies Principle (ADP) — no dependency cycles.
2. Stable Dependencies Principle (SDP) — depend on direction of stability.
3. Stable Abstractions Principle (SAP) — the more abstract, the more stable.

High-Level Architecture:

1. Keep Configurable Data at High Levels — constants or config datas should be kept in high level.
2. Don’t Be Inconsistent— have a convention, principle, rule or guidelines and always follow them.
3. Prefer Polymorphism To If/Else or Switch/Case.
4. Separate Multi-Threading Code — isolate multi-thread from rest of the code.
5. Only one level of Abstraction per layer — stay conform to existing abstraction layers.
6. Fields Not Defining State — fields holding data that does not belong to the state of the instance but are to hold temporary data. Use local variables or extract to a class abstracting the performed action.
7. Micro Layers — avoid unnecessary design layers.
8. Singletons / Service Locator — Make use of dependency injection.
9. Base Classes Depending On Their Derivatives — Base classes should work with any derived class.
10. Feature Envy — The methods of a class should be interested in the variables and functions of the class they belong to, and not the variables and functions of other classes. Using accessors and mutators of some other object to manipulate its data, is envying the scope of the other object ©.
11. Unused Coupling — avoid unused dependencies, be greedy.
12. Hidden Coupling — make sure that order of calls to different methods are correct.
13. Transitive Navigation — (Law of Demeter), write isolated code. Classes should have access to only its direct dependencies.

Environment:

1. Project Build Requires Only One Step.
2. Executing Tests Requires Only One Step.
3. Source Control System — Always use a source control system.
4. Continuous Integration — Assure integrity with Continuous Integration.
5. Overridden Logs— Do not override warnings, errors, exception handling

Laws of UX

Have you ever wondered how an App or Platform or Product has got compelling UX when compared to the other competitors of similar capabilities addressed by another?

If they are solving the same purpose or function with almost the same non-functional needs, Then the Product Owner or Product Management has to look at the UX aspects of it for sure to improve...

Refer to Laws of UX (User Experience) https://lawsofux.com/ which is a collection of best practices that designers can consider when building user interfaces.

Reference:

https://lawsofux.com/

Critical and Design Thinking

Critical & Design Thinking aims to build shared understanding, collective knowledge & sensemaking through a community of professionals from different backgrounds and horizons.

Refer to these useful resources and books at

https://library.designcriticalthinking.com/library/books

Enterprise Design Patterns (Intersection Group Book) is at

https://library.designcriticalthinking.com/library/books/enterprise-design-patterns-intersection-group-book