Well, as a software engineer who wrote first line of code in 1991 and as a CTO of a medium sized company I would disagree here. These solutions do not suck. They work, they are cheap and they are efficient in addressing the business needs. You don’t always need a developer for simple automation, just like you don’t need a computer to calculate 2+2. Abstraction leaks, third party solutions and other things you mention are not the problems that always need a solution. Developers often overthink scalability and invest time in perfection of a code which will become obsolete in a year or two because of the change in the business model. It is there you can find the art of engineering: in finding the right problem to solve, rather than working on the problem for which you know a conventional solution. Zapier is unconventional, but it takes 30 minutes there for something that a development team would require a week or two. The limitations do exist, but it often takes some courage to understand that in your specific case you can ignore them.
They work, they are cheap and they are efficient in addressing the business needs.
In my experience, they are at most two of these things. Most of the time, I see lots of businesses bend over backwards to mold their processes to match the tooling they use, or expend lots of manual labour because their business flow isn't modelled efficiently in their tooling. Impedance mismatch is the #1 factor why many business automation projects end up costing multiples of what they were initially intended to save.
These problems aren't limited to off-the-shelf solutions, it could take an experienced developer months to really learn the business process and model it efficiently. Most businesses don't allow for that in their software budget, so you get either:
- something that works, and is relatively cheap, because it was cobbled together by someone from the business (see: excel sheets, access applications or nowadays, Microsoft Flow)
- something that works and is efficient, because it was built by a team of developers in close cooperation with the business
- something that's cheap and efficient but doesn't work, because it was built by a fly-by-night developer on a shoestring budget.
The only cases where you can have all three is when the business was built around a single piece of well-designed software, the CTO and CEO have been very conscientious about following the capabilities of the software, and the software manufacturer never decided to completely overhaul their interface for "reasons".
The biggest problem is that a lot of them are siloed, sometimes seemingly intentionally.
E.g. we have a bunch of stuff in Airtable. It's great. You can do amazing stuff with it, and it has a great API for most things.
Except for the change history and comments.
When you're aware of this, it is fine, but the moment your business processes start depending on using the comments and change history, you're locked in unless you're willing to use phantomjs or similar to log in and use the API (of course there is one) that their web client uses to access the comments, in a way that is a massive pain.
I'm happy for users to start building stuff and automating stuff. The bigger problem is when they don't design and don't understand the trade-offs. Often it works great for years, until it doesn't and you have a massive job untangling dependencies in some cobbled together solution.
Sometimes that is worth it.
Sometimes it causes you to incur costs far higher than what you saved initially because knowledge often gets lost as these system grow in complexity without any coherent thought behind them.
Very often, even if you end up using these tools, you'd still be far better off if there was still a review process to get someone to say "stop,if you do it this way you're creating a risky dependency, do it this way instead." Or to say "we really need the dev team to handle this."
It’s indeed a job of solution architect or CTO in smaller companies to do this review and develop a strategy telling, when something needs to be replaced by a custom code. Also it’s important to look at the costs not only in absolute values, but also relative to the IT budget. It’s ok to spend later 200K instead of 50K now if company revenue is going to be 10x higher or if your current budget is consumed by a more important project. Cost of money and resources can be different.
