Monday, March 20, 2017

Saturday, January 28, 2017

Your SOUP is Leaking - Crafting Acronyms

I've been making a lot of acronyms lately. Acronyms can help us think about, remember and communicate a concept. A good acronym, like a good word, can fundamentally change the way we understand the world. 

Until recently, civilization didn't have a word for blue. It's true! Business Insider has a surprisingly good article about how no ancient civilization had a word for blue. Even more surprising, it might be true that civilizations without a word for blue couldn't even see blue - at a conscious level. They had the same hardware, but their software wasn't tuned to thinking about blue, and therefor they couldn't see it. 

Words enable thinking and communicating. Without the word blue, how would you describe the color? You might say "it's the color of the sky," but as the lovely children's book Sky Color demonstrates, the sky has colors across the spectrum. You might point to other blue things, but it turns out in ancient cultures basically there weren't any blue things. Blue is extremely rare in nature, and no-one is going to build something they don't have a concept of.

Concepts are powerful. Concepts embodied in a word, more-so.

Picking a Good Acronym

Really, we are talking about making up a good word or a good, new-use of a word for a concept. Acronyms work because they provide a built-in mnemonic for remembering them. I find the stickiest acronyms reuse existing words such that the other meanings of that word somehow reinforce the new concept.

Traits of a good acronym:
  • Pronounceable - if you want people to use it, they have to be able to say it
  • Real Word, preferably with related meaning - the stickiest acronyms use this (see above)
  • Fun or Funny - make it playful so people play with it - and start using it
  • Phonetic - if it isn't a real word, make sure it's a least phonetic. If someone hears it, they should be able to write it down without having it spelled out.
  • Short - shorter == stickier
  • Clear Expansion - the expansion should be clear and succinct. It should embody the essence of the new concept.
  • At Most 1 Forced Letter - sometimes the expansion is 'forced' to match the acronym. Letters are left out or added to make it work. The more forced, the less sticky. 

My Favorite Case Study

  • Real word
  • Super clear expansion
  • Real-world wet vs dry makes a nice analogy between code with and without repetition respectively.
  • When I first ran across DRY maybe 7 years ago, I went "yeah!!!" Someone summed up a vague concept in my head succinctly and clearly. Ever since it's almost become a mantra in my daily practice. It's been a significant influence in my ever-deepening understanding of programming.

My Acronyms

  • ZEN code has many traits in common with Zen-buddhism sense - serene, minimal
  • The expansion very precisely describes the programming pattern.
  • In both these ways and the fact it's pronounceable and spellable, it beats out YAGNI.

EVA - Essence Vs Artifact
  • Pronounceable, short, phonetic, though not a real word
  • Clear expansion
  • I find it fun and pleasant. Maybe I've see WALLE too many times. I always here his voice when I see the word.

POET - Principle of Exposure and Transparency
  • Real word. One might say good poetry is both clear and has depth. This concept is mostly about clarity, but the concept itself has a lot of depth. I know that's a little forced, but every synergy between the real-word and the concept gives the acronym lift.
  • I forced 1 letter - the 'of' is included, but the 'and' is not.
  • Including the word 'principle' could be considered another form of forcing. All these acronyms are in some form 'principles' - why is this one so special it needs to be included explicitly? Nothing. It just works!

NINO - Natural-In, Natural-Out
  • Pronounceable, short, phonetic
  • Expansion suggests a question - what is 'natural'? This is key to the concept - get thinking about how to make our UIs as natural as possible for humans. There is no definitive answer what that means.
  • Oh so much better than WYSIWYG as an acronym. 
  • The NINO concept is bigger - a superset of WYSIWYG.

WLC - Write Less Code
  • NOT pronounceable or phonetic - I hesitate using the acronym at all. However...
  • The expansion is awesome. It's super catchy and a hugely important concept. I use it all the time in my presentations. 
  • WLC just becomes a shorthand. I -never- attempt to pronounce the acronym. ('wulk'? - ick)

SOUPShowing Our Undies Programming
  • expansion is funny
  • real-word
  • real-soup is not a good thing when mixed with computers, and it isn't when mixed with code
  • The SOUP concept is a form of leaky-abstractions - and real soup can leak :). If you've used up 'your undies are showing' jokes, you might say to a coworker 'your SOUP is leaking.' It's a nice synergy.


Go MUYOA (Make Up Your Own Acronyms)! If you've got a concept you are revisiting regularly, try figuring out a way to capture it in a word. Who knows, it could catch on and the world could see blue for the first time!

Wednesday, January 25, 2017

SOUP - Showing-Our-Undies vs Conscious-Programming

Have you ever thought, while using an application, that it should be doing this work for you? A great example is reload buttons, in particular the pull-down-to-reload UI on many mobile apps. Why should the user need to tell the app when to update its data? The app should know and automatically update its data the instant it changes.

The problem is programmers getting lazy. Programming is hard. Programming problems can be hard. And sometimes... Programmers just push the problem onto the user - they ask the user to press a reload button instead of automatically updating.

This mentality is ubiquitous. Apps everywhere expose the inner problems of the program that are irrelevant to the user. We programmers get lazy and let our undies hang out in public.

SOUP is about Quality

Laziness is not the only cause of SOUP. Real-world budget constraints and the need to get-to-market lead to cutting quality. Hard problems to solve in programming often get pushed off to the user with the conscious or unconscious justification that it's 'easy for the user to do.'

Presenting the user with an amazingly-well-designed app is the key to success, and yet it's easy for us to forget that and let 'real-world' pressures cause us to degrade the user's experience. This destroys the magic and results in a second-rate app that is much more likely to fail.

SOUP is about Culture and Normalization

The other major problem is culture. We become normalized to a certain kind of app working a certain way. We forget to stop and ask if there is a better way for the user to accomplish their task. I think spreadsheets are in this rut. Fundamentally they haven't changed since the original Visicalc. They are great for getting started, but once you have more than a few dozen cells with calculations, they become a bear to use. 

Programming tools are always improving. Often something that was hard in the 1970s is now easy in the 2010s. However, many UIs are still written as-if we were using the tools of the '70s, '80s or '90s.

Conscious Programming

The term conscious-blah is used for many things these days: conscious-living, conscious-eating, conscious-parenting, etc. Open up google and type in 'conscious a' or any other letter of the alphabet and you'll see some similar terms show up. 

I think all of these mean the same basic thing. We can't be conscious of everything all the time, but we can shine the light of consciousness on as many things as we can think of for a brief time each. It's about creating a practice of revising our assumptions, actions and thought processes periodically to make sure they still hold true. Incidentally, I've had a live-motto since well before the conscious-everything craze which sums this up nicely: question everything

I advocate for conscious-programming because there are many unfounded assumptions in programming - many artifacts which distract us from the essence of what we are trying to do. My post on Amazingly Great Design has some ideas on how to effectively focus on the essence of delivering value to users and cut through the jungle of artifacts.

Tuesday, January 3, 2017

Beyond CORS

The Problem with CORS

The App Principle: A web page is an application. In order for web pages to remain relevant in an app-driven world, web-apps must be able to do anything native apps can.

CORS breaks this principle. It restricts the information a web-app can fetch from the internet, and even if you are allowed to fetch it, it sometimes restricts what you can do with that information. Native Apps can fetch anything from the internet and do anything with it.

CORS has other problems as well. It isn’t consistently implemented across browsers. Safari 9.x interprets HTMLImage.crossOrigin differently from other browsers. CORS setup is difficult to get right and therefor it’s easy to get it wrong and actually create exactly the vulnerabilities CORS is supposed to prevent. Last, CORS returns extremely opaque errors.

Why Does CORS Exist?

I’ve been trying to understand this question for a year. My best understanding is, before CORS, web-apps were even more restricted. CORS opens up cross-domain access while preventing hacks such as:

  1. attempts to fetch your emails from; if you are logged in with, without cors, it could do this!
  2. CORS “taint” - I just don’t know. Is this a way to appease copyright holders? It doesn’t really prevent anything since Native Apps aren’t restricted in this way. Further, all you have to do is set up a basic web-proxy server and your Web-App could do anything with any image on the web.

CORS is the Wrong Answer

Reason #1 above is the main reason for CORS. It is legitimate from a certain perspective. There is a potential vulnerability, but it is the wrong solution. The problem is when “” attempts to contact “” it gets to freely use your cookies authenticated with This is something Native-Apps cannot do, so why should a web-page get to do this? And yet IT CAN - without CORS restrictions. This is insane. It’s like logging into the Gmail Native App on your phone , and then switching to MyMalicousApp and allowing it to send requests to Gmail using your login information from the Gmail app.

Beyond CORS - Sandboxed Cookies

It is relatively easy to solve the CORS problem now that we have separated the essence from the artifacts. We just need a way to allow websites to make external requests without giving them access to all the client’s cookies. The answer is to treat each webpage as a separate, isolated application with its own, sandboxed set of cookies for all the other webpages it communicates with.

I propose we add an option to XMLHttpRequest called ‘useSandboxedCookies’. When true, any web-application for a given domain is now allowed to make any request to any url - just like any native app could. However, all cookies used in those requests are local to that web application. This is exactly how native-apps work.


  • Alice logs into directly.
  • Then she goes to, which attempts a GET from
  • The cookies in the GET request to are empty - the GET originated in the sandboxed cookie-space of the app.
  • So, even though Alice is logged into in one tab, in the tab, requests to appear to be coming from a new session.

This solution doesn’t actually do anything you can’t already do with CORS. All you need to do is set up a proxy server (example: corsproxy), which returns all the right CORS headers, and any website can fetch data from anywhere on the net, taint-free. However, setting up a proxy is not generally an option because it is costly, inefficient and not library-friendly. We need a client-side solution like the one above.

  • We should do away with the Taint concept entirely. It doesn't achieve anything useful, but it creates a lot of developer pain. Therefor, Sandboxed-cookie-requests should never return tainted objects.

Safe, Cross-Web-App Communication

My useSandboxedCookies proposal above solves 99% of the CORS problem. Since it could be added to the HTML spec in addition to CORS, we could stop there. However, there is another use-case that my proposal prevents but CORS allows, however poorly.

There are legitimate reasons why MyGoodWebsite might want to access using Alice's logged in credentials, and may want to allow it. For example, may want to offer a ‘log in with Gmail’ feature to third-party web apps. My proposal above prevents this since the only client-side code allowed to access Alice's cookies is’s code itself.

We need a reliable way for two client-side apps to communicate with each other. To do this, we can add a relatively simple extension to the postMessage API: allow postMessage to post a message to a URL. When this happens, the browser fetches data from the specified URL to initialize a headless client-side javascript session. That session can then send and respond to postMessages with other client-side web apps.

In the example above, MyGoodWebsite could postMessage to Once the gmail app loads, it sends back a postMessage that it is ready. Then MyGoodWebsite can use Gmail’s custom API for authentication. The app can then use the user’s already-authenticated cookies to communicate with the servers and authenticate the third-party app.


I've outlined two proposals which superscede CORS and solve its problems:

  • Sandboxed Cookies: allow a web-app to safely fetch data from anywhere on the web without a simple client-side flag set per request, without any painful 'tainting.' Tainting is depricated.
  • PostMessage to URL: Allow any web-app to start any other for the purpose of safe communication and safe use of authenticated cookie credentials.

I have wasted way too many hours on CORS over the past few years, and I'm sure I'm not the only one. These proposals are simple to use and implement. They would open the web up to the web itself, instead of just native apps.

Does anyone know how to get the attention of the HTML5 standards committee?

Thursday, July 28, 2016

Simulations and Chosen Realities

My best guess about the future is eventually we will all be “uploaded into the cloud.” (awkward, but it gets the meaning across)

It’s tempting to say we’ll all be living in a ‘simulation’ at that point. But, I think by that point we will select a new term.

When we say ‘simulation’ we mean something somehow inferior or an approximation to the ‘real thing.’ The problem with that notion is our perception of the ‘real world’ is always an inferior approximation of the real thing.

Therefor experience and perception are always a ‘simulation’ of the ‘real world.’

If we live in the cloud, and we experience a world that is generated for us by algorithms, as long as that experience is AT LEAST as accurate as our ‘real-world’ experiences were, then I don’t think it’s fair to call it a simulation anymore.

It’s something more. It is a ‘chosen reality.’ In some sense it will be inferior since the ‘real world’ will always be more complex and nuanced than our generated ones. But the difference will be beyond our ability to perceive it. Our chosen reality will be superior perceptually. It will be the reality we want, not the one forced on us. 

Wednesday, July 6, 2016


What-You-See-Is-What-You-Get was always an awkward acronym. Say "wizzywig" and people just look at you strangely. There is an amusing anecdote about the origin of the acronym on Wikipedia. I hope it's true:
The phrase "what you see is what you get," from which the acronym derives, was a catchphrase popularized by Flip Wilson's drag persona Geraldine, first appearing in September 1969, then regularly in the early '70s on The Flip Wilson Show. The phrase was a statement demanding acceptance of Geraldine's entire personality and appearance. wikipedia 

NINO - Natural-In, Natural-Out

The idea, though, is powerful. Being able to see what the output of your work looks like as you edit is a tremendous relief to the mental burden of creation. It was a hot idea in the '80s and '90s, but it is equally important, and often ignored, today in 2016.

The main problem with WYSIWYG is it is only half the equation. How we put information into an app is equally important as how we get information back out. Just as we shouldn't have to perform mental gymnastics trying to anticipate how our final output will look, we shouldn't have to wade through a bewildering array of options to get our ideas into the app.

The best interfaces are the ones that get out of the way. You know an app is well designed when you completely forget the interface and instead can dedicate 100% of your mental energy towards your creation. These interfaces tend to have two things in common.
  1. They visually get out of the way. There is less screen clutter to distract you.
  2. Their feature-set is restrained. They avoid presenting you with too many options. Instead, they are carefully designed to have the bare minimum essential tools you need to create great stuff.

Comparison: Paper by FiftyThree - a NINO App

As of version 3, Paper by FiftyThree extended its excellent sketching app with note taking features. They introduce a brilliant set of natural gestures for formatting your notes that required zero screen clutter.

Comparison: Microsoft OneNote - a very Un-NINO App

By contrast, consider OneNote. It has a bewildering array of features, buttons, icons, widgets and text. My note in the screenshot below has a short title and one line of text. It is oppressively dominated by the rest of the interface.


Our devices, phones, tablets, computers, watches and more and more becoming extensions of our mind and body. I once heard a description of smart-phones, particularly with notes and productivity apps, as our exocranium. These devices and apps are becoming our brain outside our brain. The better the app, the more natural an extension of our mind and body. The better the app, the more natural its inputs and outputs - the more NINO it is.

Sunday, June 12, 2016

WLC - Write Less Code

Given two solutions to a problem, the one with less code is usually better. 

Plite of the Programmer

Our job as programmers is to deliver value to customers. We deliver value by identifying needs, translating them into requirements, and writing code to meet those requirements. The difficulty of the task is compounded by the fact that requirements are constantly, unpredictably changing. Even after we finally ship, the story isn’t over. Code is a living thing that must be maintained, usually well beyond anyone's expectations.

Over the lifetime of a product, we will edit code 10x more than we write code, and we will read code 10x more than we edit it. Each token we add to our code may be read over 100 times. Every token we save could save up to 100 token-thoughts and 10 future edits. The key to our productivity is writing less code.

Why Count Tokens?

Tokens are the smallest meaningful element in code. Tokens are a more objective measure of code size since lines can have any number of tokens. Measuring tokens also ignores white-space and comments. Last, measuring tokens doesn't penalize using clear names. ‘Occupations’ is just as good a name under the token metrics as ‘occus’ or other hard to understand abbreviations.

Don't abbreviate words. Saving keystrokes only saves writing the code. It doesn't save edits or reading. Abriviations make reading harder. Since reading code dominates our time, abbreviations are a losing proposition. Only use shortened words if the shortened version is used at least as commonly in speech.

Measuring tokens is a simple, effective metric that lets us make decisions quickly and get on with solving problems and delivering value.

Why ‘Write Less Code’?

It's a simple concept with depth. Amateurs and masters both can apply and learn from it. A more accurate metric might be refactorability. We spend most of our time refactoring code, not writing it. Refactorability is the code-quality metric. It can be broken down into code size, clarity, and structure. Of the three, size is the only one that can be objectively measured, and while clarity and structure are important, both are usually improved by reducing code size. Refactorability is not something a novice will understand. ‘Write less code’ is an excellent guiding principle for all programmers.

How to Write Less Code

All other good coding practices essentially reduce code size. Two of the most important, and most often violated coding practices for reducing code-size are DRY and ZEN.


Don't. Repeat. Yourself. Don't you dare repeat yourself ;). The most problematic artifacts I've seen, both from novice and expert programmers, is code repetition. The big problem with repetition is it compounds the complexity of refactoring. Not only do we have to fix two or more things instead of one, but we have to understand how they all interact. Plus it bloats the code-base making it hard to understand.

DRY is a subtle art. The first, obvious level is ‘don't copy-paste your code,’ but as we level-up, we start to realize anything gzip might compress potentially violates DRY. The ultimate measure is, as always, refactorability. How many code-points need to change for a common refactor? Is there a way to reduce repetition to reduce the complexity of refactorability?


Build it with Zero Extra Nuts (more commonly known as YAGNI). Because it is impossible to
predict future requirements, adding anything to our code that isn't strictly necessary to meet current requirements is not only a waste of time now, but it will haunt us for at least 10x future edits and 100x future reads.

It is fun to add cool features, but the master knows the only thing that matters is delivering value to the customer.

Write Less Code - Formalized

My hypothesis, and my experience, comes down to this:

  • Given two different functions, modules or programs
  • that both meet or exceed the problem's requirements, both correctness and performance
  • the one with less tokens is always better
  • as long as it doesn't sacrifice clarity.

The Practice of Writing Less Code

As with everything in life, writing less code is a practice. There is no point where we will master it. There is always another layer of deeper understanding. We are always learning how to make our code DRYer and more ZEN. We must constantly be looking for ways to meet requirements with less code.