Reflections on TTW Programming from the Future¶
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.
Comments
comments powered by Disqus