A classic from the community formerly known as the Airtable Community, this piece deserves a home where it can actually be found. I left in the original links to Goldbergian Buffoonery, and such a search in the new Airtable Community reveals nothing; I think I was censored. This link might be insightful, though.
I tend to work in the Kuiper belt of complex and challenging integration projects at scale, but I’m not isolated from occasional simple problems where I can learn something while helping others. I also advise many investment groups and companies concerning the bets they place in no/low-code systems and vendors.
With vast experience in fishing woefully architected systems from a cesspool of low/no-code Airtable Goldbergian buffoonery, I feel compelled to offer this advice if you are seeking the right person to lead the development of your future Airtable tech stack.
An appeal to candidates who are low/no-code “experts” is risky because it will entice and attract people who have many skills that have done some amazing things with Integromat, Zapier, and other platforms. But there’s another side of no/low-code power users that may result in the creation (or expansion) of costly, unreliable, and largely unsustainable processes. Some of these candidates seeking work will be ideal; most will not.
This is not to say that low/no-code solutions are impractical or lack investment worthiness, but it is an indictment of the skillset of the typical power-user who has been empowered by the various glue-factory vendors that offer magical and enticing ways to marry systems, data, and events.
In many cases, these application adhesives are a dance with the devil and lacking a deeper understanding of data modelling with a clear focus on the application architecture, there will almost certainly be surprising but sometimes very disappointing days ahead for your solution.
My advice - set the bar a little higher by looking for evidence the no-code/low-code candidates are clearly planning and building solutions with strategic, scalable, cost-effective and serviceable scepticism.
Ask them simply to define “technical debt” or explain the nature of a Goldberg Machine and how to avoid the pitfalls associated with complex dependencies.
I’ve learned that there are two types of no/low-coders:
- Those who understand the nature of technical debt, but tend to do everything possible with glue and duct tape to create the best outcomes given the constraints.
- Those who only want to see it work (sometimes just once) and get paid.
Your appeal for help should try to slam the door on candidates who are type #2.
Just sayin’ …