Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Look ma, No Frameworks
Pablo Chacin
Motivation
So, you are a
Java developer?
What frameworks
do you use?
I don’t use any
framework
What’s wrong with frameworks?
This is not (only) a rant
against frameworks,
but an analysis of the
consequences of using
t...
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...
“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
s...
Easy Yet Complex
“Many complicating
constructs are easy
to use. However,
what matters is the
complexity they yield.
And su...
Power Requires Discipline
“And because you
stand on the shoulders
of giants, you can
accomplish something
quickly. You don...
Restriction in Choices
“Why did I leave .NET?
In short, it constrained
our ability to choose and
turned our focus towards
...
Design as Learning
“While we all need to
write code that others
can use and maintain, I
hope part of that
process involves...
“How do you teach
magic to junior
developers?”
Greg Young, 8 lines of code
The Problems with Magic
Why Agile Development won’t help
“Software gets about 10x
bigger each decade. So while
our attention has been
focused on f...
Hints for a Solution
Create a vision
Follow a risk driven
design process
Document relevant
elements in a
meaningful way
Define your Style
Provide
a vocabulary
to describe
your system
and reason about
its properties.
Unix’s Pipe Style
Write programs that
do one thing well
and work together
by handling text
streams as a
universal interfac...
The problem with styles
Msg. Passing EventsPipes Micro Services
(a.k.a SOA)
OOP
Document Relevant Structure
Follow a Risk-Driven Process
Identify risks due to
project, team, or
technology factors
Architect until main
risks are cov...
Risk storming
Technical risk
(failures, data
inconsistency,
incompatibilities, ...)
Stakeholder’s
concerns (cost, time,
pe...
Architecturally-Evident Code
Close the model-
code gap by
adopting an
architecturally-
evident coding style,
embedding in ...
Conclusions
“Life is pain. Anyone
saying differently is
selling something”
Iñigo Montoya
Questions? … Thanks!
Acknowledgements
1. Keep calm.., source: http://www.keepcalm-o-matic.co.uk/
2. Iñigo Montoya, source http://velvetgeek.com...
Upcoming SlideShare
Loading in …5
×

Look ma, No Frameworks - JBcnConf 2015

2,811 views

Published on

Frameworks have become ubiquitous in software development: ORM, MVC, etc. Even when it's generally acknowledged they impose some undesirable limitations to design, it's also commonly accepted as a necessary evil because they offer a productivity which would be impossible to achieve without them... or can it be possible? This talk presents the experience of developing a large scale, complex application without using any framework, and how just sound design principles it was possible to beat deadlines with high code quality.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Look ma, No Frameworks - JBcnConf 2015

  1. 1. Look ma, No Frameworks Pablo Chacin
  2. 2. Motivation So, you are a Java developer? What frameworks do you use? I don’t use any framework
  3. 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. 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. 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. 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. 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. 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. 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. 10. “How do you teach magic to junior developers?” Greg Young, 8 lines of code The Problems with Magic
  11. 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. 12. Hints for a Solution Create a vision Follow a risk driven design process Document relevant elements in a meaningful way
  13. 13. Define your Style Provide a vocabulary to describe your system and reason about its properties.
  14. 14. Unix’s Pipe Style Write programs that do one thing well and work together by handling text streams as a universal interface.
  15. 15. The problem with styles Msg. Passing EventsPipes Micro Services (a.k.a SOA) OOP
  16. 16. Document Relevant Structure
  17. 17. Follow a Risk-Driven Process Identify risks due to project, team, or technology factors Architect until main risks are covered
  18. 18. Risk storming Technical risk (failures, data inconsistency, incompatibilities, ...) Stakeholder’s concerns (cost, time, performance,...)
  19. 19. Architecturally-Evident Code Close the model- code gap by adopting an architecturally- evident coding style, embedding in code hints about design intent
  20. 20. Conclusions “Life is pain. Anyone saying differently is selling something” Iñigo Montoya
  21. 21. Questions? … Thanks!
  22. 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

×