This document discusses the downsides of frameworks and provides alternatives. It argues that frameworks can do too much and constrain choices. Alternatives proposed include defining an architectural style or vocabulary, following a risk-driven design process, and documenting relevant elements of the system in a meaningful way. The key is to write programs that do one thing well and work together through well-defined interfaces, rather than relying on large frameworks.

1. Look ma, No Frameworks
Pablo Chacin

2. Motivation
So, you are a
Java developer?
What frameworks
do you use?
I don’t use any
framework

3. What’s wrong with frameworks?
This is not (only) a rant
against frameworks,
but an analysis of the
consequences of using
them and a proposal
for alternatives.

4. Frameworkitis
“Is the disease that
a framework wants
to do too much for
you or it does it in a
way that you don't
want but you can't
change it”
Erich Gamma

5. “We might have been able to use
Ruby on Rails. But It also adds a
bunch of requirements for stuff you
then have to write
so everything will
work nicely with
your framework”
Node at LinkedIn: The Pursuit of Thinner, Lighter, Faster
Unneeded Stuff

6. Easy Yet Complex
“Many complicating
constructs are easy
to use. However,
what matters is the
complexity they yield.
And such complexity
is incidental to the
problem”
Rich Hickey, author of Clojure

7. Power Requires Discipline
“And because you
stand on the shoulders
of giants, you can
accomplish something
quickly. You don’t even
know exactly what you
have done.”
Dr. Ian Malcolm

8. Restriction in Choices
“Why did I leave .NET?
In short, it constrained
our ability to choose and
turned our focus towards
safety instead of helping
us experience all of the
possibilities out there”
Jonathan Oliver, Why I left .Net

9. Design as Learning
“While we all need to
write code that others
can use and maintain, I
hope part of that
process involves trying
to increase our
collective knowledge”
James Coglan

10. “How do you teach
magic to junior
developers?”
Greg Young, 8 lines of code
The Problems with Magic

11. Why Agile Development won’t help
“Software gets about 10x
bigger each decade. So while
our attention has been
focused on fixing process
problems, our software got an
order of magnitude bigger. In
my opinion, it's time to turn
our attention back to design.”
George Fairbanks, Just Enough
Software Architecture

12. Hints for a Solution
Create a vision
Follow a risk driven
design process
Document relevant
elements in a
meaningful way

13. Define your Style
Provide
a vocabulary
to describe
your system
and reason about
its properties.

14. Unix’s Pipe Style
Write programs that
do one thing well
and work together
by handling text
streams as a
universal interface.

15. The problem with styles
Msg. Passing EventsPipes Micro Services
(a.k.a SOA)
OOP

16. Document Relevant Structure

17. Follow a Risk-Driven Process
Identify risks due to
project, team, or
technology factors
Architect until main
risks are covered

18. Risk storming
Technical risk
(failures, data
inconsistency,
incompatibilities, ...)
Stakeholder’s
concerns (cost, time,
performance,...)

19. Architecturally-Evident Code
Close the model-
code gap by
adopting an
architecturally-
evident coding style,
embedding in code
hints about design
intent

20. Conclusions
“Life is pain. Anyone
saying differently is
selling something”
Iñigo Montoya

21. Questions? … Thanks!

22. Acknowledgements
1. Keep calm.., source: http://www.keepcalm-o-matic.co.uk/
2. Iñigo Montoya, source http://velvetgeek.com/
3. Architecture Documentation, Code naming example,
source http://www.codingthearchitecture.com/
4. Risk Storming, source http://www.doyoubuzz.
com/michael-keeling/cv/blog
5. Node at LinkedIn: The Pursuit of Thinner, Lighter, Faster,
source http://queue.acm.org/detail.cfm?id=2567673