unfiltered

A few observations about complexity while working on my agent library.

1. One of the foundational decisions that we have to make when designing software is where to place complexity. In a way, designing is about discovering complexity and shifting it between the user and system. As designers, we are making assumptions and decisions about what to solicit from the user and what to bake into the design.
2. Complexity here refers to decisions or steps taken as part of accomplishing a task. An example of complexity is something as mundane as naming a file. They are often trivial as individual units, but when accumulated they can make a task feel complex and frustrating unless the user is well trained.
3. Software is excellent at encoding decisions programmatically and is thus great at removing these from the user. There was a movement around sensible defaults a decade ago or so that aimed to decrease the amount of decisions that needed to be made out of the box. The end result is perceived simplicity.
4. There is no free lunch however. By its nature, simplicity is diametrically opposed to control. What is made not explicit must be implicit, either in terms of effort required to discover them or the ability to access them in the first place. In the latter case, it will sometimes make a design awkward–that is, users will have to contort themselves to take advantage of it–or, a non-starter.
5. It is extremely difficult to hide complexity completely. If a choice can be completely removed without consequences, then it is either redundant or obsolete. The reason options exist and matter is because users are not a single homogenous bloc. People want to make use of technology to achieve certain means and the diversity in needs and preferences are as kaleidoscopic as people themselves.
6. Sometimes new technology can emerge that changes the landscape of complexity. Language models are a prime example of that. The ability to use language–one that is native to us–as the medium and interface opens up much more possibilities compared to the crude resolution of commands and GUIs. This introduces new possibilities and thus complexity into the system. Current AI apps punt them onto the users but as the field develops, we will start seeing the complexity shift again.

I recently purchased a Tanita scale, and it’s been a reminder that good products are delightful. It was an opportunistic purchase. Somehow I shattered the kitchen scale that I had for years and not too long ago I saw a chef’s recommendation on YouTube.

The thing about the Tanita is that it’s as if someone has thoroughly considered what makes for a good home kitchen scale and made the scale-iest home kitchen scale that they can make. The performance is impeccable; it displays weight changes instantly and there’s even a precise mode that goes down to 0.1g (fun fact: coffee beans are about 0.2g each on average). The controls are logical and satisfying. One of the problems I had with the previous scale is that it did not have an off button - it turns off automatically and frequently when I’m in the middle of using it. Lastly, it feels good in the hand, a hefty enough chunk but small enough to stow away. Also, the raised platform separate the weighed to the weight display and that’s a nice touch.

I expected to like the scale but I didn’t expect to love it. I find so much joy in weighing things and knowing how heavy they are that I’m constantly finding excuses to use it. Everything from weighing out my morning coffee beans to pasta servings. Good products should make you want to use it more, find new ways of using it, and just shout it’s virtues from the rooftop. That’s the standard I need to hold myself to when building new products.

I love learning. It often involves looking for new sources of information to drink from. There is an exhilaration from discovering the untapped land of knowledge and a rush from venturing through it.

Yet to my recent surprise I discovered that the once topic of my disdain, repetition, is an equally great teacher. Through the integration of a few daily practices I have found them to be a profound source of satisfaction. Repetition is the king of compounding effects. Inches accumulated over time paves major new thoroughfares.

Doing a thing, whether it is a movement, technique, or habit, over and over again yields insights and opens up new areas of exploration. Maybe it is the small adjustments that repetition demands, the continual solving of micro problems, or simply the comfort of familiarity that frees the mind to wander. Whatever the reason, repetition fosters mastery and creativity.

It’s very hard to do a thing over and over without becoming skilled or without eventually getting inventive. Moreover, this knowledge can only be gained through repetition. The insights are embodied and ingrained in the motion–not something one can read or listen to.

I used to dread practice. Now, I look forward to it.

Recently, I have taken back to sketching out ideas by hand again. To achieve a neater and more compelling final composition, I found it really useful to work in layers.

The first layer is always a rough placement of where things go. Subsequently, I will refine content and details, ink the outlines, and finally add color and shadow. Every pass is an attempt at both fleshing out the idea itself and achieving balance between the elements. Finally, the pencil lines are erased, the scaffolds taken down, and what is left is the final polished composition.

This is going to sound profound and basic at the same time: iteration isn’t optional – it’s essential. Good design demands iterations because it only emerges from progressively refining ideas from rough concepts to detailed compositions. No one, no matter how talented, can do it all in a single pass.

Product design mirrors this truth. Understanding a problem thoroughly demands multiple iterations. Every pass is an opportunity to uncover new insights to elevate the status quo towards something better. Unlike paper and pencil, modern tools often err on the side of too much gloss. This is a reminder to myself that at the fundamental level iteration, more than any tool, is how we get to great products.

In business they often talk about bundling unbundling cycles. In product, the countervailing forces are width and depth, that is to be as broadly applicable as possible, or as narrowly applicable as possible. The worst place to be is at the middle because one can neither reap the effects of being de facto solution nor fitted like a glove to a niche.

Going wide is typically suited for first movers within a new domain and those who seek to challenge them. To take a contemporary example, ChatGPT is the broadest solution in AI Chat today, and they established their position by being an innovator in the field. To play in this arena, new players will have to find nooks and crannies where ChatGPT is no longer a good enough solution, or, mount a full frontal with all the resources they can muster (against all of OpenAI).

The common saying in startup circles is that if one can find 10 customers, one can find 100 (there is risk of overfitting at one). At first glance, the business opportunity may seem enormously asymmetrical, but two things. First, financial rewards are disproportionate; the most lucrative is often overlooked. Second, product molded to specific niches may find a larger market available to them over time because the practices in those areas surface to mainstream (think tools like kanban).

First exist. Then play.

I have been thinking about thrownness ever since I’ve learned about it from Winograd and Flores’s Understanding Computers and Cognition¹.

Wikipedia defines thrownness as the following:

Thrownness (German: Geworfenheit) is a concept introduced by German philosopher Martin Heidegger (1889–1976) to describe humans’ individual existences as being ‘thrown’ (geworfen) into the world.

As I get older, I am starting to believe that we often experience things first, then we make up stories to justify our behaviors. We weave in our felt sensations, our internal motivations, and subconsciously or not our desires as well.

Design, by its contemplative nature really likes constructing stories. Stories like user journeys, especially when stripped of contradictions, become alluring totems that we use to burnish the glean of our designs.

We build flows and interfaces with our perfect information of what we want the user to do. People, on the other hand, experience our designs with what they know and want to accomplish. They do not have knowledge of or care for the frameworks that we attempt to ruthlessly simplify into. Real life is messy and people are thrown into the rhythms of life and have lots of things to worry about other than clicking through our perfectly constructed contraptions.

I am not arguing for abandoning stories or frameworks. They work for a reason. What we need to do is to have less faith in stories but consider them sufficiently so that we can deliver good outcomes, and not so much such that we become prisoners to them.

Sometimes, the best we can do is to watch other people use our software and we’ll realize that how broken everything is.

I got nerd sniped into adding a table of contents into my Jekyll blog. I don’t know, because I think it looks cool (here’s an example). Getting nerd sniped therein of itself is not terribly interesting, but having AI help with nerd sniping is a game changer.

Despite my love for Jekyll, I don’t read or write Ruby. I find the syntax incorrigible. In this case, I was using the venerable jekyll-toc plugin and it was lacking one key thing that I want to do, that is, render the table of contents only when there is something to display. After banging my head against the wall on search engines and shuddering at the thought of submitting a pull request in Ruby, I turned to ChatGPT for a solution.

The result was a short and sweet custom plugin, my first ever on this site. At the end of the day, I’m glad this one day-ish excursion is no longer than it needed to be. I’ll count that as a win.

module Jekyll
    module CountHeadersFilter
        def count_headers(input)
        return 0 unless input
        input.scan(/<h[1-6].*?>.*?<\/h[1-6]>/i).length
        end
    end
end

Liquid::Template.register_filter(Jekyll::CountHeadersFilter)

See? Incorrigible.

There are a certain set of settings that we set once and then we forget why we set them. Recently, I ran into an issue where localhost does not resolve (consistently) to 127.0.0.1 on my local machine. A quick diagnostic revealed that it has something to do with the DNS resolver, and specifically, something to do with pointing it to 8.8.8.8. At some point I stopped digging because it’s not worth the time to untangle the why – I simply needed to unblock myself.

These occurrences, that is discovering my esoteric actions in the past, happen a few times a year, and a few year gap between in each morphotype. I’ve tried a few different solutions, from leaving comments inline (I don’t have the foresight of knowledge), to jotting down in notes (which now creates an all-encompassing chore), and nothing quite works. I then either spend hours trying to understand the system again or unblock myself to the extent necessary.

The thing though is that I am a proponent of software customization. Settings are good! We should be able to change things to suit our needs. The question is customization creates an exception case, and when that exception meets the mainstream and our memory fails us, how do we gracefully resolve them. That is, ensuring that the intent of the change is honored while paving a path forward for whatever that needs to get done.

Design thinking loves happy paths. It does make me wonder, what does the design literature and the collective intelligence have to say about this. What is the best way to handle plurality in systems?

At this point, AI writing code is inevitable. People I know are, understandably, worried about the impacts on our vocation. I don’t profess to be prescient about the upcoming effects, but I have a different take.

I’m hopeful that one possible consequence of pervasive AI generated code is that there is much more software functionality to go around. It may sometimes feel like we have a lot of software around us, but if examined closely, its effects are unequally distributed. As an example, ad-serving platforms (financially lucrative but debatably socially positive) have humongous and robust stacks while restaurant websites (personally positive) are positively impoverished.

Software is hard to build right. It is, at its best, a delicate dance done right between requirements, design, architecting, writing good code, and giving a damn. As a result, people gravitate towards building things once and building it right. Which is why people want to be opinionated, build frameworks to incorporate best practices, and the resulting power law distribution of adoption and resources.

AI writing code can change all that. If code can be written quickly with sufficient quality, and more importantly, cheaply, then code doesn’t have to always conform to the most common denominator (or popular opinion). The consequences of lowering this bar will be immense. Small businesses can break free from the big platform or janky home grown dichotomy. Software that conforms to natural workflows instead of vice versa (goodbye to enterprise software contracts). People can rewrite user interfaces to suit their abilities, needs, and preferences.

I am most curious to the last one. Because of the cost of building software, design has always have a citadel like quality to it. We profess to be the whisperer of what our users need and direct the provision of them in software modules. What if users no longer need this layer of translation? I don’t think this will lead to better designed software; it may instead lead to generally terrible software, except that in this world every jagged rock is someone else’s gem. We may truly enter the era of personalized software. To push it into the logical conclusion, seams and structures of software today will cease to exist and instead we will have access to capabilities on our terms, on demand.

It is a challenging framing to consider even beyond considering the existential threat to our livelihoods. For me, abundance upsets so much of what we take for granted, rituals and expectations that are built up over decades of the computing industry. But that may all be for the greater good. Or not. Interesting times indeed.

A theory is by its nature a partial account of reality—a set of blinders through which some aspects of the world are highlighted and others become invisible. Design is by nature both holistic and ruthlessly simplifying. A designed artifact, whether it is a piece of communications software or a city park, must address the complex mixture of human needs, embodied in a weave of physical and social interaction. But the design itself cannot embody all of these complexities if it is to be constructible and understandable. The design must embody a simplification,leaving room for the texture of the world to be filled in by the interpretation and practices of those who use it. (emphasis mine)

– Terry Winograd. 2006. Designing a New Foundation for Design. Communications of the ACM 49, 5 (May 2006), 71–74. DOI: https://doi.org/10.1145/1125944.1125978

I think about this quote a lot.