This document discusses the differences between simple and easy in software development. It argues that while ease provides initial speed, simplicity is better for long-term development and maintenance. Simple software uses single roles, tasks, concepts and dimensions, is objective, and is within our skills and capabilities. The document recommends writing simple code using constructs that generate simple artifacts, abstracting to simplify problems, and not over-engineering solutions. Overall it promotes composing simple components and modularity to achieve strong, maintainable software through simplicity rather than complexity.

1. Simple vs Easy
Irfan Omur
Android Developer at Twentify

2. Goal
Convince yourself and others to do the right thing

3. Word Origins
Simple
vs complex
Easy
ease > aise > adjacens
vs hard

4. Simple Easy
● One role
● One task
● One concept
● One dimension
● Objective
● Near, at hand (on our hard
drive, in our tool set, IDE)
● Near to our
understanding / skill set,
familiar
● Near our capabilities
● Relative

7. Changeability
● Changes to software require analysis and decisions
● What will be impacted?
● Where do changes need to be made?
● Your ability to reason about your program is critical to changing it without fear

8. Debugging
● What’s true of every bug in the
field?
● It has passed the type checker and
all the tests
● Your ability to reason about your
program is critical to debugging

9. Development Speed
● Ease gives early speed
● Ignoring complexity will slow you
down over the long haul

10. Making Things Easy
● Installing tools
● Become familiar by learning, trying
● We can only consider few things at a
time
● Complexity undermines understanding
● But mental capability?
Limits

11. New tools, libraries
● They are great! Let’s use it!
● But
○ Drawbacks?
○ Increasing simplicity or
complexity?

12. Compose
● To place together
● Composing simple components is
the key to strong software
● Simplicity is not about count
● Build with more components rather
than fewer

13. Compounding components

14. Modularity and Simplicity

15. Programming is not about typing, it’s about thinking.

16. Simplify
● We choose simple tools
● We write simple stuff
● Sometimes simplify already written stuff
How:
● Use constructs that generate simple artifacts
● What matters are artifacts not the authoring tools
● Simplify the problem space before starting
● Use abstractions aiming to simplification

17. Abstracting
Answering
● What
● Who
● When
● Where
● Why
● How

18. We are not engineers.
We are not scientists.
We are writers. - Bruce Eckel
We write stories.

19. Do Not Over-Engineer
● Libraries, guides are tools, not goals.
● The goal is to ship and maintain
● Don’t use something just because X does.
Their problem is not yours, neither their
solution.
● You don’t need to do it from day one. First
have the problem, then solve it.

20. ƒ(easy,simple)

21. Easy and Simple

22. Simplicity is the ultimate sophistication
Leonardo da Vinci

23. Thanks!
References: Simple Made Easy - Rich Hickey, Simplicity in Practice - Luke VanderHart, droidNYC2017