Monday, August 29, 2016

Book Review: Understanding the Four Rules of Simple Design

Understanding the Four Rules of Simple Design

by Corey Haines

Great technical book with tons of distilled advice about software design. It is mainly focused design at a class level, but some of the advice can be extrapolated to a macro design level.
I enjoy a lot the book and it is easy to read and to understand, but it requires at least a medium level of OO design experience to learn from the content. Definitively not a entry level book.

The contents of the book come from the experience of Corey Haines hosting many code retreats. At this code retreats, the problem to solve is always the same (Conway's Game of Life), so Corey show lots of different designs for the same problem. Using this problem and code as a base, he explains the four rules of simple design proposed by Kent Beck in the initial XP book…

This book can help any developer to improve his designs skills and interiorize how to implement elegant and simple designs in his programs. Lot of wisdom.

Even the foreword from Kent Beck contains advices that are pure gold

Sunday, August 21, 2016

Agile is not a recipe for success...

Post previously published in Spanish agilidad no es una receta para el exito

Agile is not a recipe for success, is a recipe for failure...
Fail fast, cheap and learning during the process... Agile will not avoid the failure, but it will help to avoid failing in the same way, at the same problem or using a ton of resources.

Agile assume the following:
  • We will fail to estimate.
  • We will fail to understand the customer's requests.
  • We will fail to select technologies.
  • The requirements will change (always).
So agile proposed:
  • Estimate very small chunks (or no estimate at all).
  • Deliver running systems to obtain feedback and adapt the system to the real need of the customer.
  • Use agile practices to have under control the technical debt and to allow maintenance/evolution of the system with a reasonable cost.
  • Maximize the amount of work not done.
  • Create code with good quality to make very easy to adapt it to future changes.
And all of this using very fast/small cycles (timeboxing, iterations, continuous delivery), so even if we fail is very difficult that this failure generates a great problem.

And all this process reinforced with a continuous improvement process (with retrospectives and team improvements).

Embrace Failure
Embrace Change
Embrace Chaos

Sunday, August 14, 2016

Why I use the term "software craftsman"

I like to think that I can consider myself a professional software developer after 20 years or working on it. Since some years ago I feel very aligned with agile software development movement and lately with the software craftmanship movement. I started to be interested in agile in 2002-2003 and in the software craftsmanship in 2012.
Currently when I try to describe myself I use the words “software craftsman” as an equivalent to “software developer, continuously trying to improve his skills and craft”.

Let me explain what I mean by “software craftsman”:
  • I mean being professional as software developer
    • Trying not only to create working code, trying to create simple, easy to maintain code.
    • Trying not only to create the code that the business required, also trying to help the business to growth (with different solutions, even without using code). Adding steadily value to the business.
  • In order to be a good professional there is a strong need to learn and improve our skills, tools and practices. Or even look for new ones.
  • IMHO a good process for learning or improving ours skills is participating in the community of professional software developers. In this process the mentor / apprentice format works very well to improve our skills.
Why not using the “agile software developer” denomination?
In fact, for my, this definition can be a good option, but currently, the term agile is even more confuse that craftsmanship.

For me, at least in my experience, the development of applications and systems has more in common with a craft than with an engineering. Engineering is the application of mathematics, empirical evidence and scientific knowledge, so it is possible to plan, predict and control. IMHO software development for non trivial systems requires sense and respond and other approaches can derive in a false sense of control.

Some kind of software efforts are more adapted to a engineering approach (algorithms, compilers, software for science), but in my case, this is the exception, not the norm.

So, currently in my linkedin profile I indicate that I work as Software Craftsman… I also indicate that I work as a Shaman, but this is different history :-)


aws-sdk-go spikes and small examples

I am developing the initial support for aws checks for the library

gochecks library allow us at TheMotion and at AleaSoluciones to create programmatically highly concurrent monitoring apps.

This post is an autonote with the initial spikes created using the aws-sdk-go