Abstractions and Platforms

I've come to appreciate the Go communities advice on abstractions.

Avoid creating abstractions prematurely. Every abstraction has a cost, and often duplicated code is simpler and easier to maintain than a premature abstraction.

Don't take DRY (Don't Repeat Yourself) to an extreme. It is perfectly fine to duplicate code several times and only create an abstraction once you see a clear pattern and understand better the problem the abstraction is solving.

For instance, in Simple IoT, we implemented a number of subsystems (rules, modbus, 1-wire, etc.) before we noticed a pattern -- all of these systems needed lifecycle management, which is very tricky to get right. So it made sense to create a client abstraction that handled lifecycle in one place. But it was not clear what we really needed until we had implemented several subsystems.

Follow the YAGNI (You Ain't Gonna Need It) principle -- only create abstractions when you need them, not for hypothetical future use cases.

The same applies to platforms.

Other than avoiding architectural pitfalls and selecting the wrong technology, focus on building out YOUR Platform to solve your current needs, not your future needs. This is one of the best ways to know if your architecture and technology are right.

Platforms for the sake of platforms are detrimental and counter-productive -- kind of like the IT department that loses its focus that they are there to serve the business needs and becomes a barrier to getting things done. They must serve the business goals, not themselves.

A platform in itself provides no value if you are not shipping something of value.

The same can be said of any supporting role or metric -- finance, performance, etc.

If you are not shipping (internal prototypes and test versions count as shipping), nothing else matters.