##############################################
Reflections on TTW Programming from the Future
##############################################

    Playing with `IFTTT`_ and `Zapier`_ has me remembering the TTW programming fallout
    and debate.

I've been working on `feeding my ABlog posts to social media`_.  I've been experimenting
with some external services for this, primarily because implementing something
self-hosted seems like overkill for this and it makes an excuse to explore something
I've been wanting to.  I'm intrigued by these services that claim to let you connect
little pieces of functionality, through an intuitive UI, to create "custom"
mini-"applications".

I'm old enough to have cut my teeth on `some of the first Through-The-Web (TTW)
programming offerings`_ and thus long enough to watch the problems that became of
that. The consensus among the communities I've been involved in is that it's a bad idea
to invite users and tinkerers to build their own custom applications with the promise
that it's easier and achievable because they can do it in their browser.  The issue is
*not* that non-programmers can't learn to program.  They certainly can and I object to
the kind of rarefied elitism that leads others to argue otherwise.  The issue is that no
one can build the kind of custom application one can build with a full programming
language without *also* learning most, if not all, of the suite of programming best
practices.  Without those best practices, one is all but guaranteed to end up with a
poorly engineered, unmaintainable mess.  The best case scenario is that your application
fails to become useful and thus never has a chance to become a burden.  That leaves
those who manage to create an actually useful, initially successful application that
users come to depend on.  These successful tinkerers are eventually rewarded by hitting
multiple walls at once.  Thinking about, planning for, and executing on maintainability
and other best practices are simply costs that must be paid.  The apparent savings of
not having to think about such things is an illusion and those costs have been
compounding all along behind your back.

While the 10th feature was as easy to implement as the 1st, the 100th feature is 10
times as difficult as the 10th and breaks features 20-23; you can infer the curve.  You
took a stab at a major version upgrade of the framework months ago, hit another wall,
and set it aside.  Now the security/LTS of your major version is about to expire meaning
your custom application will soon be vulnerable to multiple publicly available exploits.
Change management is becoming a nightmare with duplicated code all over the place in an
effort to compensate.  A while back, you learned about VCS and the current best-of-breed
in that domain but you also realized that you couldn't use those tools to manage your
TTW code.  There are better ways to build custom applications even within the framework
you're using, but not TTW, the effort is comparable to re-implementing the application,
and those that can do it justly charge much more.  BTW, having learned so much from
this, you're now worth a lot more yourself and are recruited into your first junior
programming job.  Those last two are good things, but the end result is that a team of
users is now dependent on a custom application that's going to cost them a lot to either
replace or maintain.  They became a company in the business of developing software
without ever intending to, planning on or budgeting for.

That whole process breeds resentment in a way that doesn't come from even an equally
blundering and costly but conscious effort to develop one's own custom software.  Like
much of human happiness, it's expectations, the surprise, that's the issue.  That's how
I understand the issue with TTW programming.  If a framework provides anything
approaching a full programming language, *and* offers or promises to save
users-come-developers some portion of software development "hassles", then everyone is
almost certainly in for some bad-will inducing surprises.

So that means that any system that allows users to assemble "applications" through a UI
meant to spare them from some portion of software development discipline needs to have
clear, rigid boundaries on expectations.  It needs to narrowly define what can be done,
place firm limits on the size of what can be built (roughly, the quantity of
components).  It doesn't hurt to provide users an eject button so that they can export
what they've done to the filesystem and continue developing it incrementally using a
full software development tool chain and process.  These are the lessons the `Plone`_
community tried to learn from our `Zope`_ TTW roots.  The `Plone`_ community built web
UI based on these conclusions for both custom content types with custom schemata and for
custom themes.

Given my involvement in that long (for software) history, I've been wanting to check out
`IFTTT`_.  Such custom applet "development" and hosting platforms are solving different
problems, very simple workflow applications connecting various internet services, but I
imagine theses same principles apply.  `IFTTT`_ seems to employ these principles quite
firmly.  I'm not aware of any eject button that could meaningfully allow one to
incrementally build software on top of `IFTTT`_ applets, but that wouldn't be terribly
useful anyways given how firmly they restrict the scope of what one can do.  I don't
have any current need for anything beyond IFTTT's simple, two-step composition model,
the ``this`` component and the ``that`` component in "If this then that", but I could
well imagine wanting more than that.  There's also the limit on 3 applets on the free
tier of their freemium pricing plan, I am already using 2.  Finally, I couldn't find a
``then`` component for posting to LinkedIn as a service, that's the one that really lead
me to seek other options.

I ran across `Zapier`_ a while back and was similarly intrigued, so when that showed up
in my search for something that could post to LinkedIn, I eagerly tried it out.  They
offer 5 applets, which they call "Zaps" (bit of a groaner of a term), on the free tier
of their freemium pricing plan, so point for `Zapier`_.  I haven't read much of their
docs, but it's apparent in the web UI that there's support for at least a somewhat
arbitrary chaining of more than 2 components, another win for `Zapier`_.  I also found
their options for dealing with different "fields" in data, `atom feed`_ items in this
case, to be significantly more rich than those offered by `IFTTT`_, `Zapier`_ streaks
ahead.  They do indeed have components that interact with LinkedIn, so `Zapier`_ FTW in
this very cursory and superficial scoring.

In the current moment, I'm very curious to see how the more restrictive `IFTTT`_
compares in the long term to the more feature-rich and composible `Zapier`_ in terms of
user experience, user maintainability, and *internal* maintainability.  Even if I were
to pay enough attention to keep up on this, not very likely, I'm even less likely to get
access to the kind of proprietary internal discussion that could yield such insight.
C'est la capitalisme.  At any rate, It's been fun to reflect on the issue while
automating some things.

.. _`atom feed`: https://ablog.readthedocs.io/manual/ablog-configuration-options/?highlight=feeds#blog-feeds

.. _`IFTTT`: https://ifttt.com/
.. _`Zapier`: https://zapier.com/

.. _`Zope`: https://zope.org/
.. _`some of the first Through-The-Web (TTW) programming offerings`: `Zope`_
.. _`Plone`: https://plone.org/

.. _`feeding my ABlog posts to social media`: ../feeding-ablog-to-social-media/

.. meta::
   :description: Playing with IFTTT and Zapier has me remembering the TTW programming
                 fallout and debate.
   :keywords: Zapier, IFTTT, Plone, Zope, TTW

.. post:: Apr 7, 2021
   :author: Ross Patterson
   :tags: Zapier, IFTTT, Plone, Zope, TTW