Simple Made Easy

Recorded at:

Summary
Rich Hickey emphasizes simplicity’s virtues over easiness’, showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path.

Bio
Rich Hickey, the author of Clojure, is an independent software designer, consultant and application architect with over 20 years of experience in all facets of software development. Rich has worked on scheduling systems, broadcast automation, audio analysis and fingerprinting, database design, yield management, exit poll systems, and machine listening.

Strange Loop is a multi-disciplinary conference that aims to bring together the developers and thinkers building tomorrow's technology in fields such as emerging languages, alternative databases, concurrency, distributed systems, mobile development, and the web.

Sponsored Content

Key Takeaways

We should aim for simplicity because simplicity is a prerequisite for reliability.

Simple is often erroneously mistaken for easy. "Easy" means "to be at hand", "to be approachable". "Simple" is the opposite of "complex" which means "being intertwined", "being tied together". Simple != easy.

What matters in software is: does the software do what is supposed to do? Is it of high quality? Can we rely on it? Can problems be fixed along the way? Can requirements change over time? The answers to these questions is what matters in writing software not the look and feel of the experience writing the code or the cultural implications of it.

The benefits of simplicity are: ease of understanding, ease of change, ease of debugging, flexibility.

5:16 The origin of "easy" implies "nearness". Something that is near can be easily touched or grabbed.

Simplicity vs. easiness in software development

5:58 In software development, easy means being near to our understanding, being in our skillset, being familiar.

6:20 Easy is overrated in the software industry. "Can I get this running in 5 seconds?" It does not matter if the result is a large ball of mud. All it matters is to be done quickly.

7:03 All that is new is somewhat unfamiliar. Do not avoid it even if it is harder to grasp or do at first.

7:14 People usually feel uncomfortably to say about something that it is beyond their capabilities.

8:17 Easy is a relative term. Something may be easy for someone and difficult for someone else.

8:44 Many times, developers say about some that is simple, but they mean easy, because they mean it is something they are familiar with.

9:05 The distinction between simple and easy is relevant when dealing with software constructs and artifacts.

9:36 The attributes of an artifact are how it runs, what's the performance, how it can be changed over time. These attributes are not the original construct (code).

10:06 People focus too much on the construct, on how easily they can write something or how easily is to replace one developer with another, considering just the familiarity of the tools used, not the simplicity or complexity of the code the new developer needs to deal with.

Why simplicity matters in software development

11:36 We should ask ourselves these questions: does the software do what is supposed to do? Is it of high quality? Can we rely on it? Can problems be fixed along the way? Can requirements change over time? The answers to these questions is what matters in writing software not the look and feel of the experience writing the code or the cultural implications of it.

12:34 "We can only hope to make reliable those things we understand". And there is usually a tradeoff. When evolving a system, making it more extensible and dynamic, it may become harder to understand and decide if it is correct.

13:24 People can juggle only a few things at a time, a small number. The same with the number of things one can think of at one time. That becomes even harder when things are intertwined, because one cannot reason about them in isolation.

35:40 State is easy but introduces complexity because it intertwines value and time. State intertwines everything it touches directly or indirectly, and it is not mitigated by modules and encapsulation.

Rules tend to increase complexity through constructs such as conditionals, flow control, etc.

Try using a declarative or a rule system to keep things simple.

56:06 Information is simple. Keep it simple. Don’t use an object to handle information. That’s not what objects were meant for. We need to create generic constructs that manipulate information. You build them once and reuse them. Objects raise complexity in that area.

57:00 If you have a map, use a map construct. Don’t create an object for it. Leave data as data. Do not tie data logic to its representation. Avoid ORM.

58:10 Simplicity is a choice. We have a culture of complexity. Avoid tools (languages, constructs, etc.) that generate complex outputs. Simple != easy. Look for complexity and avoid it. Reliability tools - testing, refactoring, type systems - are good but secondary. They do not enforce simplicity. They are just a safety net.

There is an interesting overlap between the notion of "complect" as interleaving of concepts and the notion of entanglement in software, as discussed in an ongoing series on the "physics of software" by Carlo Pescio. Here are two relevant links:

Comparing Easy and Simple in this form is brilliant. But in this form they are also just Your personal opinions. Projection of Your "inner mental model" of programming, modeling etc.What is missing, are facts. Maybe examples of non-trivial and non-hello-world problems and code/diagrams with some sort of measurement of complexity.Personal opinions can be considered but only in the context of some kind of psychological personality types that determines "feeling" of complexity.That could also help preaching Clojure:)

If you liked this talk, you might be interested in attending the new Clojure/West conference in San Jose, CA, March 16-17th. Rich Hickey will be doing a keynote at Clojure/West, along with Stuart Halloway, Bradford Cross, and Richard Gabriel.

Thanks for this excellent talk, it actually aplies to more than just software. If you stretch this simplicity all the way to the customer's needs, I'm sure the value of our work will be better for it.

When trying to split things up, some developers are actually uncomfortable of having many components because that feels like it will be hard to find out what is happening where. When working with queues, it's are harder to debug a program.

Thanks, this is a very nice video!Also, I'm a fan of Clojure and other multi-paradigm languages (like F# where "active patterns" is kind of "multi-methods").

Some comments:

1)"Clojure and Haskell refs compose value and time"... So is this like reactive programming?Like programming set-operations against a set of events (event storage/event loop/audit trail/transaction log/history/whatever you call it)?

2)Pattern matching is very close to multi-methods ("polyphormism ala carte").Multi-methods can be used to separate the reasoning from the method. So, yes, you can think it makes this one method simpler. But there is still this reasoning somewhere. "Polyphormism ala carte" has its places, but replacing matching everywhere as best practice would just hide information (a bit like IoC).

Great talk. Neat idea to contrast the tension between easy and complex. Liked the examples.However, there is one aspect of complexity that I felt was not really explicitly addressed. This is that a braid like structure is the hallmark of high levels of functionality in nature (see e.g. Figure 9.1 in Reengineering Philosophy, which compares the decomposition of a lump of granite and a fruit fly, illustrating what the book calls descriptive simplicity and complexity). If we want to build highly functional systems, then the challenge is to find some way of capturing descriptive complexity with lego-like components (sometimes called deep simplicity).

Yet again, another talk that takes a personal, negative experience and paints it as gospel.

That crap about the starting pistol, about rebuilding stuff that has been done already may well be applicable to the author's projects, to the author's experiences. But I would posit this: how about you've just been working in bad company, and in a bad company. Because I do t experience the same stuff you do. The key difference is that just because I have experienced it one way, it doesbt mean I am going to pretend that my personal experience is the norm, or should be a basis for a new religion. I can look at it objectively and think to myself: well it looks like this stuff works and this stuff probably doesn't work... in this particular situation.

The thing that irks me with a lot of Medium posts and talks like this is that it's usually a relatively young protagonist who has a limited amount of experience to draw on but insists (not thinks, not hypothesises) but insists they have the answers. These kind of arrogant statements produce a revolution one in every hundred. That's not to say discussion isn't valuable, but of there were less arrogance and more objectivity we would spend less time chasing false idols and more time making progress.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.