The DIY Software Revolution

Airtable is one of the more interesting online products that has come out in the last couple of years. With my designer hat on, I thought it was nuts.

But when I stepped back and looked at it holistically you can see how clever it is. It’s using the same principles as a spreadsheet, but with online smarts (APIs for example) that make it extendable beyond what the spreadsheet can do. And just like the spreadsheet, it can be used for simple tasks or complicated reporting tools. It’s possible to push the possibilities further. Sometimes it’s worth taking off your designer hat.

The CEO Howie Liu touches on this approach in the talk above, as well as giving a quick history of software development approaches that contain useful ideas for today.

My notes (there’s a tonne of notes for this talk) 

Designers take complexity and assess not important dimensions (then remove these from the user view).

Function and form

Data model and logic – function

Visual layer – form

For example, Weebly and Squarespace prioritise the form, not the function.


From the 60s to today the way we think about programming hasn’t changed that much. It’s a bunch of code in text.

Looks as daunting as it did in the 1960s.

“We haven’t made the same leaps and bounds with programming”.

Writing code = a narrowly scoped way of understanding a problem. Code doesn’t equal software.


Series of instructions that tells a computer to do something.

The tools we use to manage and manipulate information.

Lacks focus on the value of humans who use information.

Information could be:

  • Your Pokemon card collection
  • Cattle
  • Equipment.

Human scale information – represents information as we know it.

Check out Bonnie Nardi’s work. She is a HCI academic.

Computer deals with information/data. -> Knowledge sits with the person.


They learn that their changes affect the output of the system.

MIT – scratch

Program structure


is represented as puzzle pieces. They have visual affordance.

They can be pieced together to make the system do certain things.


Game development software for kids.

In the past there has been different radical approaches to rethinking programming. Visual programming is one way.

Text-based code is inherently linear.

Flow-based is one way of rethinking this.

Quartz composer etc.

Mathematic Hupercard

Myst – visual system.

Why isn’t there more impetus to do more about visual programming? 

It’s hard to take novel approaches. Places the burden on the developer to put in sweat and hours.

Spreadsheets are a good example of a user-centred ‘programming’ tool.

How do you model the data of the world around you?

Google, Facebook, Microsoft.

Tools to manage your own informational version of the world.

In 1990s innovation died out in terms of software/programming approaches. This was a convergence of reasons:

  • Internet
  • Lots of tools with a narrow value proposition started popping up
  • Microsoft dominated and washed divergent voices out of the market.

We moved toward simplified experiences with our systems.

In design we looks for ways to reduce choices.

Perhaps we need to start designing for possibilities and tinkering.

“Junk food push-button experiences”.

User as driver approach has become the widespread model.

For software to get to the next step, we need to look to some of the (programming) ideas of the past (1960s – early 90s).

Let’s use kits as a paradigm to design our systems. 

Keep the barrier of entry low.

Cater for shallow, immediate experiences but also provide depth to allow the person to achieve mastery/bend the system to their own will.

“A lot of applications we use now are very shallow for example Dropbox. But for kits we want it to be an onion”.

  • Declarative – here’s the constraints. Solve within the constraints.
  • Imperative – do x then y.

Here are the dimensions of systems:

  • DOM
  • Logic
  • Interface layer.

Instead of prioritising the visual layer (Squarespace etc) why don’t we provide tools to manipulate the logic layer.



Steve Blank on Why some startups win

Why Some Startups Win

“I wasn’t surprised. When organizations are small (startups, small teams in companies and government agencies) early employees share a mission (why they come to work, what they need to do while they are at work, and how they will know they have succeeded). But as these organizations grow large, what was once a shared mission and intent gets buried under HR process and Key Performance Indicators.”

Goal setting for startup success

This is the second post about Sally-Ann from Google in about a week. The stuff she’s saying is resonating with me.

Some notes from the video

Consider the unique aspects of ‘you’ and what you bring to the organisation that no-one else can?

Make sure you bring your voice to the org. (This is an interesting one for me personally.)

How can I insert myself into the DNA?

State your:

  • Vision &
  • Mission.

Write it down. Stick it on a wall. Externalise it. Don’t keep it in your head.

When you do that your first employees will understand how they fit in.

(My note: I don’t think I’m 100% on the difference between vision and mission at the moment. Need to do some more reading.)

Sally-Ann also mentions OKRs.

Founders keep stuff in their heads.

Remember that people are your biggest asset.

Becoming as big as Google.

The first think is to have the ambition and the drive.

The second thing is to work out the strategy to achieve it.

Then do the hard work to execute the strategy.

“The only thing that will hold back these women is themselves”.


The MVP is dead. Long live the RAT.

“There is a flaw at the heart of the term Minimum Viable Product: it’s not a product. It’s a way of testing whether you’ve found a problem worth solving. A way to reduce risk and quickly test your biggest assumption. Instead of building an MVP identify your Riskiest Assumption and Test it.”

MVP is one of those phrases that seems to have about a million different interpretations, depending on who you ask. Riskiest Assumption Tests make the purpose of the thing (prototype, other artefact) explicit. “We are building this thing to test our most risky assumption, then we’ll move onto the next”.

The trouble I’ve observed with MVPs in different workplaces is:

  • it’s hard to actually define – what is minimum really? and,
  • how do you actually coordinate all the thinking required from different disciplines to build a product without burning a bunch of time and including things that are not minimum.

The MVP has always been a fairly difficult concept to understand, even though it appears simple before you think it through.

The RAT is definitely worth considering.