I build data pipelines. These are the three things I hold every one of them to.
Scalability
Growth should not force a rebuild. Not only more data, but a new use case, a new type of data, a new kind of problem. A good design takes those in by adding to it, not by tearing it down.
Reliability
Things will break: sources change, jobs fail, data arrives late. A reliable pipeline expects that. Running it again gives the same correct result, a failure never leaves half-written data, and bad numbers are caught before a user finds them. And it is reliable only when that has been checked against the real system, not because a command printed "success".
Maintainability
The test is a new engineer. They should be able to read the codebase and catch up fast, because it explains itself: plain code over clever code, small parts that are easy to change safely, and tools behind interfaces, so replacing one doesn't mean rewriting the rest.
Coming soon: Pipeline Lab, where you can break a real data pipeline (run it twice, change the schema, send late data) and watch how it holds.