As my quote attempted to make clear, it is not an indictment of glue-like services such as Zapier; rather, it is a cautionary reminder that using them to overcome certain types of challenges in any solution - specifically where multi-pass algorithms are required - come at a cost and sometimes a very steep cost. That is the point where many users find themselves going around the barn many times. The price of a “working solution” often becomes expensive in terms of added complexity. And added complexity in tables often results in an erosion of usability.
I think we can both agree that there are limits to what can be done without code. I’m simply suggesting it’s good to assess the nature of the solution to make sure the accommodations we must make to avoid writing code are well worth the outcome.
Indeed, it’s all about solutions as you point out - we both certainly agree that something working is generally better than nothing. And in many cases, a working model is an ideal stepping stone that may someday transition into a sustainable solution with fewer moving parts, better reliability, and scalability without added services costs. But we must also be mindful of solutions that are brittle.
I think - as consultants - we also share an obligation to advise those less experienced concerning the possible downsides of any implementation approach. There are some cases where these tools are simply a bad choice, and I think members of the community would like to be aware of potential pitfalls.
Lastly, solutions that are created using third-party adhesives tend to muddy the waters in small and large companies and for many reasons.
- Dependencies that have hidden costs.
- Dependencies that may change without adequate notice.
- Dependencies that create security risks. (identities flowing through Zapier is not advised; some CSOs consider this a security breach)
- Dependencies that need to be maintained and fully understood long after the creator has left the project.
- Dependencies that create copyright and patent constraints.
Surely, there’s no point in debating the contribution that third-party integration services provide; they have their place in the API economy just as SDKs do, and just as development libraries do. But like many implementation approaches, sometimes they can make matters worse, not better.
I too have been playing with code for a few decades - almost five to be exact. Yes, I’m 67, a really old cantankerous dude! I created LapLink when I was twenty-something (53m users), dBrief (4m users) when I was thirty-something, QuikSite (3m users) when I was 40-something, MyST (16m users) when I was fifty-something, and Stream It (1 user, $4.3m contract) when I was sixty-something. As you might guess, I’m biased toward solving problems with code.