April 15, 2012

When you don't need a framework

I've been developing applications for a short time, from small to medium size codebases with many different features, requirements and environments. For all these applications I've always found the issue about the frameworks, sometimes this discussion takes days, or even weeks if the people involved is very passionate about Rails, Hibernate, JSF, CDI, and some others.

Mostly the discussions tend to be related to the benefits a framework can give us: speed, conventions, less coding, design improvements, being cool....

And for some projects the right frameworks have been a blessing, improving the developer experience and reducing development effort. But that's not always the case, because sometimes the frameworks can lead you to think that 'their' way to do it is the 'right' way.

'Their' way to do it can be 'right' for their intentions, but your application is not meant to be based on their intentions, but your customer ones. A framework should not define how your application is structured, how your business logic is wired, and not even how your tests are written.

I've always struggled with testing on a framework, because most of the times the requirements for its setup are so large, that makes you feel sick. And it's even worse if you are tied to certain technology because your customer has bought the 'sweetest' license in the market.

But well, here's my summary about frameworks:

Advantages

  • Speed, not always, but a lot of frameworks are performance-oriented.
  • Support, if it's open source, you will have a lot of it.
  • DRY, yeah, you don't reinvent the wheel.
  • Convention over configuration, very powerful, and saves lots of efforts.

Disadvantages

  • With bad design decisions, you can marry your code with a framework, and that marriage is an ugly one
  • Performance, as said, not all frameworks are performance-oriented.
  • Test difficulty, you mean that I have to setup the entire framework stack in order to test a single operation?

When to use them

  •  It's rare to find a reason not to use a framework, I would say that the question is not 'when to use a framework?', but 'how my application should be designed in order to be framework-agnostic?'.

When not to use them, or at least think twice before using them

  • When its usage doesn't give you any advantages
  • When you have a 'contractual' boundary with it
  • When your team dislikes it
  • When your tests take more than 10 seconds to setup its environment
  • When the framework itself is untestable
Based on: Architecture, the lost years - Robert C. Martin

April 10, 2012

SE books you must read: Agile Principles, Patterns, and Practices in C#

As a disclaimer, I'm a Java developer, but this book can't be left aside. If you are a follower of the Clean Code movement this is the right book for you. Perhaps the most 'engineer-oriented' book written by Robert C. Martin and Micah Martin.

It covers several concepts about agile development, design patterns, programming, anti-patterns and some code katas to have fun with.


[ Agile Principles, Patterns, and Practices in C# ]

April 3, 2012

Binary tree implementation on Ruby

I was having fun comparing the code I did in my early programming attempts in Java, and thought about how much would it take to rewrite it now, but in Ruby.



As an initial attempt, I took the widely known Binary tree, I started with the test cases and then implemented the code for them, here's the result.


I can say that it took at least ~50% less effort compared to the Java implementation, and it looks good :-)

Plan de administración de proyectos: Farmacia

Ultimamente no he publicado nada en mi idioma nativo, pero creo que ahora voy a empezar una ensalada de posts incluyendo todos los idiomas de mi preferencia :-)

En este post comparto un documento elaborado para un curso de maestría en Ingeniería del Software, no es tal vez mi mejor trabajo ni tampoco estoy de acuerdo con muchos de los elementos usados:
  • Diagramas de Gantt ( algun dia morirán, ojalá ).
  • Diagramas de Euler (deben ser mutilados junto al anterior)
  • Plan de aversión.
  • Estimaciones sobre la completitud del proyecto (nunca se cumple).
No es mi intención decir que estos documentos son inútiles, pero en mi corta experiencia he tenido mejores resultados con Extreme Programming y las metodologías/frameworks de desarrollo ágil.