== Experimental Emacs ==
Corwin's Emacs Blog



Let's face it, complexity is fun. It's also where lie the demons that demand the extra eighty percent of our time for the "final" twenty percent of our requisite functionality.

Requirements are Quicksilver

Speaking only for myself, my passion projects and so on, (and in no way for any business stallholders, technology partners, or vendors with whom I may have had the honor to work over my varied professional life), the goals of a technology project on which we seriously focus attention will tend to "wiggle", vacillating about the available surface of user experience and maintainer ingenuity to the extent we don't go to lengths to, as it were, limit debate. Iterative development is, in a sense, intended to run with this problem more than to prevent it, especially with practice such as user experience testing that may involve end-users in early phases of development before a software project is bug free, perhaps working from prototypes and mock-ups thus before anything works.

It is well accepted that complexity is a beast that feeds upon the longevity of our projects, and more directly on our users' aspirations, our own sense of rightness with the world. and other forces with diminishingly less respect for, e.g. calling it done.

But that can be fun, right? Let's make friends.

Goes To Motive

When I'm trying to defend some particularly abhorrent design decision I have stumbled upon and wish not to renegotiate, I look first to the overall flexibility a solution offers. I will often have tripped myself up in the name of "TMTOWTDI", providing alternative uses that aren't (yet) necessary, or I may have separated concerns in a manner that so far hasn't been utile. Simple questions rapidly become blush worthy as we find ourselves unpacking the hypothetical head-space of imaginary users who's interests appear steeped into our initially swagged complexities.

If we're to hold out for our village on a clover we need to ask ourselves some frank questions.

Have we realistically accessed how a user (or persona or use-case, or..) will expect things to behave? Is the contract clear in terms of what control to expect over the given feature and overall capability? Will the use of terminology and concepts used/introduced feel coherent in vision and consistent in diction considering other technology users (and maintainers) likely know?

Also, I ask myself: will I spend my time explaining this? And how worth would this be, in that event? And, if we're just a touch even more candid, there's fun thata way also: there's no small amount of counter-culture to the many and varied mystique of the programmer.

Leaving aside the petty psychoanalysis, which will quickly leave me at a loss for terms of art, let's stipulate at least that it is fun to rethink some previously trivialized concept or "anti-pattern" so that is new again, with interesting possibilities. Witness: using provided tools in unintended ways is a key technique of information security forensics such as penetration testing, which is definitely cool; so QED, pretty much.

Are We Having Fun, Yet?

For some people, I surmise, simply the set of decision making I've implied (and will shortly sketch), is fun all by it self. We start, for example, from a frustration with a product we use. We view it's source, review it's history, and find some rationale for the unsatisfactory design. Considering this, we might know of a new technique that addresses a concern raised, that way addressing the accepted reasons that were blocking our feature. (With large projects most obvious features have reached the cutting room floor one or more times, it's wise to tread carefully, and it makes for a better story.) Armed with this rare knowledge then, of advanced means to reasonable ends, we may come in swinging, especially into a packed arena, spoiler for a chance to land a few choice points in the meta while we try to land a patch that puts things right with the world. I can see where that gets fun.

For me, I think I might enjoy the complexity for it's own sake: It's a rush when I can grasp a problem that feels elusive.

But let's look at it from a risk surface perspective, considering first complexity first on a scale of "worthy-fun to unhealthy-timesuck" looks manageable for starting by considering the most complicated parts of a thing first:

  1. I might get confused and reach no conclusion saving epic amounts of my own time,

  2. I might find things simpler than expected (a treat, to be sure), or

  3. I might see how some complexity could be accessible in a potentially simpler manner (whereupon we'll have to hope this is fun as we'll undoubtedly explore further).

In contrast, if we focus first on the parts of our conceptual solution we suspect are easiest to accomplish, let's look at what we can win:

  1. if we are right, we may be able to implement a large amount of our application without inventing anything. boring, but I see where you would be going with this line of reasoning, to be sure.

  2. if we are wrong, we may be having feelings, e.g. having failed to make technology we had been thinking of as simple "just work" for our purpose, it's not uncommon to be sad and angry. Not too fun.

Admittedly that first possibility along the get-it-mostly-working-first lines didn't look too bad. But I think it's worth more closely introspecting our motives. In particular there's a real recruitment factor in capturing people's imagination with a solution that does a meaningful but incomplete set of what a number of people are hoping may be possible. Even when we don't know or suspect a rapid audience from prospective contributers, we might be more likely to attract the focus of an expert with a "scaffolding" grade solution. Honestly, and again with the strictest of focuses on only my personal and not any of my professional technology pursuits, that all basically bites.

The Operating System vision provided by GNU is of a coherent system of tools which work well and work well together, that's a clear demarcation and should be taken starkly as a way-point when we trouble to imagine contributing important new functionality to the libre/free-software ecosystem, as admittedly not all our things do.

Tell Me Again, But Make It Sound Fun

Tesler's Law drives us to consider our designs in terms of the appropriate complexity to expose to users, as well perhaps as how to compose for other maintainer and the curious, stating:

Every application has an inherent amount of irreducible complexity. The only question is: Who will have to deal with it — the user, the application developer, or the platform developer? The Law of Conservation of Complexity

Now we're down to one question: whom shall "deal with it". Fun, for sure.

I've Been Seeing This Other Problem-Space

It's not what you think. Well. It could be what you think.

Sometimes we have a pretty clear instinct about what will inevitability drive complexity into our solution. For example, let's say we have in mind a transient based interface for video workflow automation. With this we might anticipate some difficulty avoiding e.g. having some approach expressing the different tool/packages/configurations and media formats "in the wild".

This nicely illustrates Tesler's Law: we have some liberty to chose the freedoms we will offer the user, to close-off difficult to support usages in the name of maintainability, and to provide User/ Application Programming/Customize Interfaces, and thus pass the buck along, hopefully, with remarks and examples if no other "value-add".

Bring Flowers

If you are going to drop in, unannounced, unasked, with complexity someone may trouble themselves to learn, it is more than reasonable to spend some time struggling with and socializing your notions of- let's call it flexibility, as "simplification" seems presumptuous.

This could mean proposing a new format or semantic or an "intrusive" patch to existing one, or who knows. The goal will be to make a long term contract with your users about what they will need to remember about your program to install, configure, and (re)learn to use it. And too with any who may cooperate with (or subsume!) your own development, and must rationalize your decisions.

Dress for Dancing

Returning to the "goal posts" as outlined for the GNU Operating System, we can see that our mandate is to think comprehensively about our program's role among others. Seasoning our "inevitable" complexities as may compassionately conserve stresses among our users (much less respectfully distributing the burden of inventing, learning, and adopting new practice among application, platform, and ecosystem collaborators) will be a meaningful chore.