Attributes of Beautiful Systems

Fred Brooks (author of The Mythical Man-Month, an awesome book on software development) wrote another, lesser-known (but also great) book called The Design of Design. It’s broader in scope, less focused on software architecture and more on the process of design. (BTW: the terms “design” & “designers” are used in a very broad sense here)

He does not prescribe any faddish low-level process (“scrum! flat design! agile! stand-ups! story points and post-it notes!”) but rather walks you through examples of the many mental foibles that designers may stumble over.

In pointing these out, he pushes you to be more reflective about your own habits and basic assumptions. For instance: consider the value and handling of brainstorming, which is typically just assumed to be valuable. Are the ideas produced actually better? (Actually, individuals outperform groups in the quality of ideas in their originality, feasibility, and effectiveness) Do the results tend to be better when you remove criticism from the conversation? (You sure do get a greater quantity of ideas and can reach much wilder solutions than if you allowed the naysayers to shoot ideas down prematurely)

My favorite chapter, I have to say, is the one entitled “Esthetics and Style in Technical Design”. In it, Brooks explores that fuzzy idea of what makes for a “beautiful system”. People can talk about beauty for cars, airplanes, houses, sculpture -- where the object is physical and has visual beauty. But people judge totally abstract things as being beautiful too: a theorem, a programming language, even a “visually ugly” but “logically beautiful” system such as Minecraft. Visual beauty is pretty apparent; so you might wonder, what does it really mean to be bear “logical beauty”?

Brooks lays out the prime attributes that define a logically beautiful system. I’ll list them briefly here:

Parsimony

The property of being able to accomplish a great deal with few elements. This is positive only up to a point, so beware of following this to the extreme: excessive parsimony leads to the use of non-obvious idioms. You can design a language with very few elements that’s completely insane to actually code in. You can have an API that only allows incrementation (but with negative numbers): parsimonious, yes; intuitive, no.

Brainfuck Language, which consists of just punctuation.

Conway's Game of Life. Very few rules, and technically Turing-complete.

Structural Clarity

There must be a direct path from what you want to say to how you say it. The basic structural concept is plainly evident and if not obvious, then easily explained. Familiar and simple metaphors aid in this (e.g. the "Desktop" of Macintosh, the "spreadsheet" of VisiCalc, the "blocks" of Squarespace).

Consistency

Given familiarity with just part of a system, you can predict the rest of it. You'd expect all functions in a package to throw similarly formatted exceptions, use similar error codes, take similar input types. If the $increment function takes a path and number, so should the $decrement. 

Modern militaries are designed for complete uniformity. This trait evolved as a requirement to achieve scale and usability for commanders.

Orthogonality

Do not link what is independent. A change in one function does not affect another. In other words: no side effects. Air conditioning in your car shouldn’t affect the lighting (though in reality, at a certain point all these systems draw from the same power supply and in extreme situations, orthogonality breaks down)

A system deliberately designed for unexpected side effects.

Propriety

Do not introduce what is immaterial. Do not expose incidental complexity, where extraneous implementation details affect the interface. Shifting of gears in a car is completely incidental and do not belong in its interface. An example of an egregious violation of propriety: iPhones being unable to use Facetime unless connected to WiFi. This limitation is completely arbitrary from grandma’s perspective.

Generality

Do not restrict what is inherent. Generality is the ability to use a function for many ends. Designs should not make too many assumptions about the use of a function. This is where Unix really nails it, keeping standard i/o, pipes, and files completely general.

Every block can connect to any other block.

... Enabling amazing constructions.

Dynamic Typing

Dynamic Typing is like stuffing all your data into a pile of <String, Object>HashMaps and calling it a day.

It's fucking insane.

• You lost all compile-time checks.
• You will have to implement a million unit tests where a type system would have made these guarantees.
• You literally have to find a way to exercise every single code path in your system in order to avoid the simplest of type mistakes. In this sense, you are forced to write exhaustive tests.
• It's impossible, just from looking at a function, to know with any certainty what values are provided or generated.
• Given a variable, it's impossible to know the valid range of values it may contain. 

Alan Kay on putting yourself into the future

Alan Kay gave a great talk called "Normal Considered Harmful"

At 51:35 there's quite a gem. He advises us:

Don't be in the past. You need to put yourself into the future in order to skate to where the puck is going to be. You need to leverage up!

The way to get leverage is to get a ton of computer power and write a ton of very simple, non-optimized languages that run very very quickly. And you should be able to do them every couple of days to get power and then throw them away, use them like kleenexes.

Its rather easy to do that if you don't have to optimize and you don't have to optimize if you use hardware that runs 100x faster than what you have today.

So unless you do that, you can ONLY do incremental stuff today.

Another great point at 59:00

The MacCready Effect. 

Always do the minimal thing you can do that is qualitatively better. Before building anything, MacCready spent a long time thinking about where to spend 80% of his effort beore he did a darn thing. That's why he solved an immense number of problems in his life.

The truly useful thing: a Programming Systems Product

This one gem of an insight from Fred Brooks is important for any software person to know: a combined programming system product is 9x more costly than a program. 

It's useful for you to know what you're writing when you're writing it. You've probably written a lot of mere programs: one-off executables that do a single task within many constraints and a whole lot of assumptions. It's not build to be re-used, it's built to get some job done once and be thrown away.

You can start, then, to go along two different paths: the programming system or the programming product. They are both three times harder to do.

When you go down the system path you break your program apart into components, give it sane interfaces, and let it integrate into other programs and systems. It's generalized to the point that you can plug third party code into it. You can write more programs leveraging it, essentially transforming it into an API. The result is a much more powerful and flexible program that can do things you never initially imagined.

When you build a programming product you give it a measure of flexibility in its functionality (in the form of user-inputted parameters) but with a ton of effort around validation, reliability, managing edge cases, good error messaging and handling, testing, documentation, and safety. You're making something that you can basically put into a box and hand someone with a price and a warranty.

Now, the real useful thing - the real money product - is the synthesis of the two: a programming systems product. This is both general and safe, both powerful and productized. This system has massive value, but is also far, far more complex to assemble and manage.

For Squarespace; the quadrants would be:

A single website. A website templating language.

CMS (Squarespace 5). Squarespace 6. 

P and NP

Technology may be wrecking the middle class. 

This got me thinking about something my discrete math professor once said: "All problems in the world are either in P or NP. The problems in P will, inevitably, be automated and run by machines. Problems in NP are what humans are for. If you want to stay employed in the future, focus on NP."

For those not familiar with P=NP, Scott Aaronson sums it up nicely. 

This is also a great writeup in the New Yorker. 

The Deli Model of Software

Imagine you’re in a deli ordering a sandwich. You’ve decided what kind of cheese (swiss) and what kind of bread (focaccia) you want and now you’re looking at the possible meats you can put on it. Your eyes scan over all the big humps of smoked turkey, pastrami, roast beef … until you notice one weird one and wonder what the hell it’s doing there.

It’s a jalapeno peanut butter glazed ham. 

 You think to yourself: this thing takes up space in the fridge, has to be ordered and moved from a truck into shop, sorted and manually organized into a spot on the display, and then occasionally spoils and has to be replaced. All of this effort … for a couple of eccentric customers who occasionally order it? Even if it’s not a money-losing ham it’s definitely sucking up a lot of effort.

That weird ham is the equivalent of rarely used features in your product. It’s that obscure checkbox on the third tab of a config panel.

When presented with a feature request, you should fight the kneejerk response of: “Sure, why not. Just add it as an option. Another checkbox.”

Careless moves like that are the slow road to disaster.

That new option has all these characteristics:

• It adds another code path and another corner case. Because that code path is exercised by 1% of users, it’ll break one day but you’ll only find out many weeks later.

• It is less testable (or requires a special new test to be written) When something changes, the special test may break and need to be rewritten.

• It incurs mental and communication overhead across the team.  Other engineers need to be constantly aware of it to avoid accidentally introducing a side effect somewhere else that breaks it. Folks making documentation need to update screenshots and write about it. All folks in your Support department need to be made aware of it and deal with inquiries about it.

• It clutters your UI with an element that is visually distracting to everyone who doesn’t care for it. Depending on what it is, it may even give your users more opportunity to screw up. Furthermore, your designers will have to struggle with this wart forever.

• It represents exponential complexity. This is actually the most important negative effect that will cripple you over time, and the one you must be most vigilant against, because it kills you by thousands of small bites.

  The complexity of your system is NOT expressed as O(lines of code). It’s actually roughly O(2^number of checkboxes). Don’t dismiss it as “just another checkbox” and “just” a quick ten-line fix. That seemingly innocuous feature has effectively doubled the complexity. The deeper it is, the worse the compounding effect.

beware.

I'm not saying don't add options; after all, flexible and powerful software is incredibly valuable. There are ways to contain them. Value them carefully and just remember that if left to proliferate unchecked, they can become like an invisible anchor dragging behind your boat. They weigh a hell of a lot more than the twenty pixels you can see. 

 

Given finite resources, this deadweight will impact all other factors of your company: how fast you can put out new product, its reliability and quality, the level of service you provide, and the price of your service ... the sum total of which equals the scale of the impact you can have.

Convenience

People are almost always willing to surrender some quality for the sake of convenience. A landline is a far more reliable channel with much better sound, versus the cell phone which often drops calls or garbled-up signal. Despite that, I've never had a landline.

“As it turns out, it was true that the iPhone made e-mailing a more cumbersome experience. But it did everything else so much better that it didn’t matter. People were willing to give up some of the ease of e-mail use for everything else iPhones provided. ”

— http://www.nytimes.com/2013/08/20/opinion/nocera-how-not-to-stay-on-top.html?_r=0

Indirection / Transformation

​Or, by transforming the problem into one you already know how to solve.

“All problems in computer science can be solved by another level of indirection”

— david wheeler

Explorable Systems: Inviting Experimentation

Don Norman once wrote an incredible book called The Design of Everyday Things​. The book was originally going to be called "The Psychology of Everyday Things" but the title wasn't buzzy enough to market the book. The book isn't about slick visual design as you might initially think; it's actually a very thoughtful look at the way the objects around us make sense in our minds, how objects hint at how they are meant to be used, and how they convey (or encapsulate) information. This book is a must-read for anyone building tools, and is full of lessons for those of us who build software.

Anyway.​

One particularly important part (page 183) speaks of the notion of "Explorable Systems". It's how we learn about appliances, televisions, a new stereo, or video games. We often push buttons and develop a mental model of the object's behavior by looking at it and the changes in state: lights turn on, certain things can be opened, or your character (in a game) moves a certain way. This is done really well nowadays when it comes to a lot of consumer software, but is done abysmally for what we use to make​ the darn stuff: code​. 

I ask you: think, for a moment, about how poorly programming languages facilitate Norman's three requirements lists for a system to be "explorable":​

1. In each state of the system, the user must readily see and be able to do the allowable actions.
2. ​The effect of each action must be both visible and easy to interpret.
3. Actions should be without cost [...] readily reversible.

If you're a programmer and reading these, you probably just chuckled. The stuff you work with typically does none of these things, or very poorly. ​

Ever sit in front of a freshly opened IDE and wonder, what the fuck can I do with this? That's how I felt when I first ran the promising new Light Table. Before me was a blank canvas and I knew it was somehow powerful but I no idea what to do with it; I didn't see brushes, I didn't see paint, I hadn't the foggiest idea how to build a useful program with it. The system was invisible. I had to have all of it in my head. The object here (a language and compiler, hidden somewhere) conveyed zero information itself in the world.​

​What if we made code slightly more ... un-code? (And no, I don't mean some super heavy abstraction that totally nerfs your tool. Just a very light layer that lets you make the same old stuff but through a different interface than a raw text editor, where everything must be carried in your head. It would map very directly to real code, and still you'd have to think in terms of the real code, but it would guide you to write good code. Some working environment that is fully import/exportable with regular old code, but puts it into a form that is less tiring to manipulate) And still maintain the awesome underlying power of code? What if options can be laid out? What if the space were more explorable? 

Why do I, a professional, need to look up, on a daily basis, trivial things in Google like the fact that LIs can have "list-style" of either "disc", "square", or "circle"? 

Why do I have to read a fucking manual? Why can't the manual be baked into the product?​

Square

Read Quote of Brian Roemmele's answer to Square, Inc.: Who created the Square card reader? on Quora

Abstraction

​a classic.

Awesome style for sketching ui ideas

http://dribbble.com/shots/665336-Animation-1-Squarespace-6

In the future, stores won’t have shelves

question: what does commerce look like in 5 years? 10? 50?

Take a look at some of these images:​

Amazon. The most world's efficient machine for moving anything that can be experienced on a screen and put in a box.

A farmer's market. The freshest food you can find nearby.

Chobani SoHo: an ad you can enter, touch, and taste

a box of books

In the future, stores won’t have shelves.

Screens have been quite good at displacing many kinds of brick-and-mortar retail. Record shops and bookstores were the first victims. Physical print is seemingly dead, or at least being pushed to survive on tactile value (quality paper, great photos; magazines you buy because they look good on your coffee table) and not on the informational content alone. It's also pointed out a lot that in other categories, quite a few people find stuff through their iPads and this trend is gaining momentum. But it can’t go on forever; at some point we will reach an equilibrium that's grounded in fundamentals. So while Amazon. for example, is a fascinating business (one whose main ingredients are CPU power, bandwidth, hard disks, robots, boxes, and trucks), it can’t expand its reach indefinitely. It has literally become a machine for moving goods to where they need to be ... but only when they are specifically demanded.

So in 50 years, where will the line be drawn between e-commerce and offline commerce? How will the two feed into each other? Will there even be a line? Why will we buy the things we buy?

What goods are going to be mainly sold online?

​a data center

Any item with purely informational value (pure text, images, recorded music) is already there. The ones soon to follow are those with very little tactile value: commodity electronics (routers, cables, batteries, etc ... sorry, Best Buy / Radio Shack), drugs, tools, household supplies, generally disposable stuff that fills some simple need in your life but doesn't enrich it; these items don’t need to be experienced to be useful.

Of the goods sold online, which are going to be sold by Amazon-like companies?

Amazon can't sell everything in its cluttered, crappy product pages. You don't even go to Amazon unless you already know what you're looking for. On Amazon, you're going to buy a case of shampoo you need but not the next shirt or vintage summer dress or handmade earrings. Such products are going to be sold directly by vertically-integrated companies with distinctive brands, unique stories, and compelling content. They are where you discover things you didn't even know you wanted.

​Handmade Tote

​a worthless Radio Shack

When you experience goods in person, what will the store look like?

Will there even be shelves of stuff laying around in plain sight, wasting precious retail space? Try this thought experiment: if Amazon's logistics machine were INFINITELY efficient and fast at distributing goods, everyone else would use it as a platform, pushing the value of those shelves and inventory rapidly towards zero. Stores are forced to become less about stuff and much more about pitching product to you and making you desire it. Ultimately, they become more like showrooms.

In 20 years, will it be more of an immersive experience, involving a lot of interaction with the brand itself? Just imagine if you had a company selling camping gear and apparel. Maybe you'd walk into a store and see not racks and shelves but instead a tent, a fire pit, and even a wood-chopping station and it would all be arranged in a way that you wouldn't even know you were in a shop. Everything would be in a natural context. In this space, an aspirational lifestyle would already be set up before you; all you need to do is fill in the blanks by literally walking into the scene. You'll enjoy this little scene so much that you'll start to desire the items that were an integral part of it.

This is what Chobani has already done with their SoHo shop.

You walk in and there's a menu of seven different ways you can enjoy a cup of Chobani: with pomegranate and chia seeds and honey, or with blueberries and walnuts. After you place your order you're invited to observe through a window as someone prepares it, and you receive a colorful little recipe card to take home. At the end of the experience, after you've enjoyed the yogurt, (or as they colorfully called it, "a Yogurt Creation") you find that you can even keep a complementary branded glass cup. It sits in your cupboard, reminding you daily.

But ... it's on West Broadway in a fashionable area but they're selling $5 cups of yogurt, so they can't possibly be trying to be a real business. How can this be?

The entire yogurt shop is actually just an advertisement you can taste.

It's almost certainly budgeted as a marketing expense. It can be thought of as an interactive ad that helps educate a visitor of all the awesome ways you can have Chobani. You walk away thinking, "Gee, if I had a tub of Chobani and a basket of ingredients, I could have a great variety of delicious, healthy options for breakfast every day." And boom: they've sold you several months of yogurt, just like that.

How will we discover new things?

Seeing lots of awesome new things happens much more rapidly (and conveniently) online than offline. Using Flipboard, you flip through a hundred items in a few minutes. Doing the same thing by window-shopping would take you all day. But that discovery might drive an offline transaction if it's the kind of item you just need to try in person.

There will be a seamless transition from the moment you discover an item on your iPad to the moment you purchase that item in the store.

You're going to see eCommerce and offline commerce not only blur into each other but form a continuous experience. If the two work in concert, eventually we’ll have a much smoother shopping experience emerge:

One day you’re reading a design/style blog and see a fantastic new blazer.You visit that brand’s website, flip through a lookbook, and see that it’s in stock in a shop on your way to work. You file your credit card and have them reserve it. With a tap, you also have them set aside a shirt you liked. The next day, you stop by. It’s a rich scene with dressed mannequins and props that reinforce the brand image. A display illustrates the manufacturing process for their denim; maybe there’s even a real loom. You tell the attendant your name, and he brings you the items that were set aside. You try them on and really like how they look and feel. With a tap to your phone and a nod to the shopkeeper, your card is charged and you go home with the items. A receipt is emailed to you. A note is made in the database and the next time you see their website, perhaps ties that pair well with that blazer are suggested to you, thus closing the loop.

Anyways, in conclusion ...

eCommerce isn't just about taking orders. It's really about telling a compelling story about a product using images, prose, video, and music. Stores, too, aren’t about cash registers and shelves; they’re going to do the same thing, but through your senses and things you can touch. ​

Universal Programming Truth

Any recursive function can also be implemented as an iterative one using a stack.​