Tog's Paradox

It looks almost as if humans have a nearly infinite backlog of things they would do if they only had time and capability, and a limit on the amount of effort they are capable of exerting per day. Then, once new tools increase their productivity and free up a bit of resources, they pick more desiderata from the backlog, and try to also accomplish that. Naturally they seek more tools for the newly-possible activities, and the loop closes.<p>This applies to any activity, leisure emphatically included. Travel became simpler → more vacations now involve flying a plane and thus obtaining tickets online and thus comparison-shopping, aggregating reviews of faraway places, etc → omg, vacation travel is complex <i>again</i>. It just allows to fulfill more of a dream.

Tog&#x27;s paradox is the main reason why I suspect that generative AI will never destroy art, it will enhance it. It allows you to create artworks within minutes that until recently required hours to create and years to master. This will cause new art to emerge that pushes these new tools to the limit, again with years of study and mastery, and they will look like nothing we&#x27;ve been able to produce so far.

First I&#x27;ve seen this, but also: this feels like a slightly long-winded explanation of what we&#x27;re actually trying to achieve through improving efficiency and such through software, right?<p>Make things easier and improve productivity, because we humans can do more with technology. Especially relevant in the current AI dialogue around what it&#x27;s going to do to different industries.<p>&gt; Consider an HR platform that automates payroll and performance management, freeing up HR staff from routine tasks. HR teams will need to justify what they do the rest of the time...<p>This quote, though, is one I&#x27;d like to further mull: added software complexity that is the result of job justification.

There&#x27;s a flip side to this that I think is quite positive.<p>When you build a tool that improves efficiency, the users either do more with the same effort or do the same with less effort. The former might be more constructive, both are good.<p>When the tool is particularly effective, it enables use cases that were not even considered before because they just took too much effort. That&#x27;s fantastic, but I suppose that&#x27;s the paradox described here, the new use case will come with new requirements, now there&#x27;s new things to make more efficient. That&#x27;s what progress is all about isn&#x27;t it?

Reminiscent of the &quot;working for the man&quot; paradoxes:<p>- If you complete your work faster, you will be assigned more work, reducing free time as well as hourly wage.<p>- Any improvements in productivity will become the new baseline for performance.<p>- Any cost savings will be absorbed by the company, while any cost overruns will be passed on to the rank and file workforce.<p>And the &quot;conservation&quot; paradoxes:<p>- The more you reduce power consumption, the more the power company will raise rates to compensate.<p>- The reward for reducing water usage by 10% this year is a mandate to reduce water usage by 10% next year.

The examples he gives aren&#x27;t very clear. Let&#x27;s just state one that&#x27;s fairly obvious to me:<p>Back in the day, someone introduced tabs in browsers that made it possible to browse several websites in a single browser window. People loved it so much that they started running browsers with dozens of opened tabs. But then this caused more pain, because now people had too much tabs to navigate. And this sparked the creation of tab managers, which introduce more complexity in how people browse the web than they used to.

It is somewhat similar to Jevons paradox: <i>when technological progress increases the efficiency with which a resource is used, but the falling cost of use induces increases in demand enough that resource use is increased, rather than reduced</i><p>E.g. People who purchase cars with Improved Fuel Economy ends up driving so much more that they end up using even more fuel than they would have with a less efficient car.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Jevons_paradox" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Jevons_paradox</a>

This has been my experience.<p>There&#x27;s a friction, between delivering the highest reasonable Quality, yet also allowing the initial users to provide feedback, and helping us to adjust the UX.<p>I deal with that, by using what I call &quot;Constant Beta.&quot; My projects are designed to reach &quot;beta&quot; (or betta), as quickly as possible, so people can start actually using them, even if incomplete. Since I write Apple stuff, I can use Apple&#x27;s TestFlight. I tend to start using it very early in the project, and there&#x27;s often hundreds of releases, by the time it actually ships.<p>I have found that users will almost never provide feedback, no matter how easy I make it, or how much I beg, so I need to infer their usage, via requests for help, or features that I can tell are being used&#x2F;not used.<p>The stuff I write has <i>extremely</i> strict privacy requirements, so I often can&#x27;t collect metrics, or have to anonymize the shit out of the ones I do collect, so there&#x27;s a lot of tea-leaves-reading, in my work.

This is the weightlifter&#x27;s paradox.<p>Lifting weights never gets easier. Lifting weights and getting strong makes the weights heavier.

Really good piece, with which I agree.<p>Parkinson&#x27;s law seems off to me w.r.t. Tog&#x27;s paradox. Were it true, Tog would be silent because nothing would ever get more complex.<p>&gt; that work expands so to fill the time available for its completion<p>If it&#x27;s restated as &quot;that the worker expands time spent so as to fill the time available to them&quot;, it comes in line. And is more in line with my observational experience. People like to do things in their job. If the &quot;job&quot; gets easier, people invent &quot;job+&quot;, and Tog&#x27;s on the money.

Ironically, programmers could also be &quot;users&quot; in this paradox, since we use complex software tools too. As tools for making software get simpler and more productive, programmers demand more complex features (languages, IDEs, paradigms, frameworks, etc).

Oh man. I still have Tog On Interface in a prominent place in my bookshelf.<p>Sometimes I take it out and wonder at how thoughtful he was about UX and how messy and inconsistent things have become since then.

I miss mention of Parkinson&#x27;s law stated (1955) by the naval historian Cyril Northcote Parkinson in &quot;The Economist&quot;:<p>&quot;work expands so as to fill the time available for its completion&quot;<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Parkinson%27s_law" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Parkinson%27s_law</a>

We have created many innovations to speed up tasks and simplify certain jobs. These improvements are always marketed as ways to create more time for family, leisure, and personal interests. But they didn&#x27;t actually free up time for these purposes. Instead, the extra time is often filled with even more work.

This is why correctness-oriented programming methods, while popular among academics, have and always will struggle with mainstream adoption.<p>A corollary of Tog&#x27;s Paradox is that the definition of &quot;correct&quot; in a given program is always changing (as requirements evolve).<p>There are exceptions, like rocket science.

I think there should be some other saying...<p>If a business has a great product, they will seek to simplify it until they piss their customers off.<p>Like tesla removing car functions until their customers are bad or fumbling drivers. (turn signal stalks, headlight switches, defrost)

Does the increase in complexity also bring a comparable increase in value?<p>Do the gains of increased complexity justify the investments they require?<p>Even if they don&#x27;t, we don&#x27;t often dare _reduce_ complexity, marginally decreasing gains while massively decreasing cost.

Doesn&#x27;t it contradict with the Unix philosophy of &quot;Make each program do one thing well&quot;? I don&#x27;t see how cp and ls are getting infinitely more complex with time.

But this is unders the assumption that developing an optimal solution to a problem is not possible, which it is. This happens rarely though.

A lot of times adding of new features or complexity is due to competitors filling a new need. Essentially the same thing but driven differently

A similar paradox applies to interpersonal relationships: in many cases, if you try to reduce someone&#x27;s workload, they will take on more tasks and end up where they started. E.g. Wife: &quot;I&#x27;m too busy; you need to do more&quot;. Husband: cleans more. Wife: takes on the PTA fundraising auction. &quot;I&#x27;m too busy; you need to do more.&quot;

It can also be a result of the XY problem. Person wants to do Y, they imagine a software that does part of the hardest parts of Y (call that part X), and they commission software that does X. They then commission a ton of other small parts of Y to be added to the software of the course of years. Whereas an all-inclusive software to do Y from the beginning would have been simpler.<p>This issue can be avoided by product leads with vision for the entire problem.

Great, now I’m fully confident that humanity is on its road to maintain existence over all the struggle cosmological challenges might throw at it. It might do so in the form of an intergalactic bureaucracy though.<p>Now, please don’t disappoint this bright new hope, go back to your work while I sit down in my sofa watching that prophecy happening.

Not really sure what makes this a &quot;paradox&quot;?<p>Seems like a lot of words to say that, when you deliver the features users want, then they will continue to want more features. (And all these features keep making users more productive&#x2F;efficient, so it&#x27;s a good thing.)<p>And, of course, more features means more software complexity.<p>But I&#x27;m struggling to see a paradox here, or even what&#x27;s supposed to be the novel observation.