Who Builds a House Without Drawing Blueprints?

“Architects draw detailed plans before a brick is laid or a nail is hammered.
But few programmers write even a rough sketch of what their programs do before they start coding.”

Code is only the tip of the software iceberg

Code is a side effect of the programming activity

1. What the program should do.
2. How the program should do it.
3. Translate our thinking to code.

As system designers we should work mainly in the problem space (what), rather than in the solution space (how).

My Vision

Programmers should transform coding in an error-free commodity, instead of our main activity.

Example: Dynamicland by Bret Victor

We need better ways of thinking about software to oust code as our computational medium.

Some ideas for this series

• Formal specifications (e.g. TLA+).
• Model-driven Software Engineering (MDSE).
• Moldable development (e.g. GToolkit in Pharo).
• New media in the spirit of augmenting human intellect of Doug Engelbart (e.g. Dynamicland).
• Property-based Testing (e.g. Genesis).
• Type-driven Development (e.g. Idris).

Programming is the thinking we do before we code

How to think about code?

“Writing is nature's way of letting you know how sloppy your thinking is.

If you're thinking without writing, you only think you're thinking.

Specifications

Specs are what we write before coding.

Specs should be higher-level than code.

They say nothing about how to write the code (e.g. BDD or SBE).

Some References

• Augmenting Human Intellect by Doug Engelbart.
• Dynamicland by Bret Victor.
• The Human Representation of Thought by Bret Victor.
• Thinking About the Code by Leslie Lamport.
• Programming Should be More Than Coding by Leslie Lamport.
• Who Builds a House Without Drawing Blueprints? by Leslie Lamport.