Sunday, March 26, 2017

learning how to learn / Great course

"In a time of drastic change it is the learners who inherit the future" Eric Hoffer, Reflections on the Human Condition



Learning is the most important skill we can acquire to live a full and productive life in this complex, fast-paced, changing and interconnected world.
I found that the course "Learning how to learn" is a very good resource to improve our capacity for learning and to be more effective with the effort employed to learn.

The course has subtitles in different languages including Spanish, is very easy to follow and doesn't require too much effort or time.

The topics covered by the course are:
  • What is Learning?
  • Chunking
  • Procrastination and Memory
  • Renaissance Learning and Unlocking Your Potential

I truly enjoyed the lectures and the material and it helped me a lot to improve my efficiency learning new things... I also like how they introduce the "pomodoro technique" as a great tool to deal with  procrastination...

Thank to the authors, Dr. Barbara Oakley, Dr. Terrence Sejnowski and Becca Judd for this great resource...

So, enroll in the next edition Learning how to learn!!!!

Sunday, March 19, 2017

Book review: Team of Teams




Team of Teams: 

The Power of Small Groups in a Fragmented World 

General Stanley McChrystal, Tantum Collins, David Silverman, Chris Fussell 


A great book on how to generate a flexible and agile organization prepared to win in a complex world. The authors explain how they created a culture and an organization composed of a network of autonomous teams that at the same time have a shared purpose and a common context.
The most impressive thing about this book is that they described a real story of a deep transformation from a very difficult starting point:

  • A huge military task force 
  • A very solid command and control culture 
  • Several separated organizations 
  • Security risks about sharing information 

So no excuses… It can be done even in the most difficult contexts.

An indispensable book for anyone interested organizations that are adaptable, agile and prepared for this fast-paced, changing and interconnected world.

Note: An interesting podcast with one of the authors bosslevelpodcast interview McChrystal

The two pillars of agile software development




I like being agile and I can say without embarrassment that I have some experience in promoting this way of working and culture... From this experience I can say that what works in the long term is a way of working that put focuses on two things:

  • A healthy culture focused on people (collaboration, respect, team work, creativity...) 
  • Looking for quality and technical excellence (for example XP practices are a great starting point).

Too much focus on methodology without technical practices or without a lot of effort in the culture will probably end in a cargo cult agile and a failed change opportunity...

In summary, for me, from the three main points of agile (culture, methodology and practices), by default, I prefer culture and practices... A healthy culture shared among all the company, a minimal agile process and good technical practices, generate a good flow of outcomes with a sustainable pace...


By the way, this spirit fits very well with Extreme Programming (XP) and with Software craftsmanship.

Needless to say that with a good culture you can reach the rest of necessary ingredients, but it is necessary to have a clear vision of the destination and spend time and effort....

For sure, this is only my opinion and is only based on my experience, but, you know, this is my blog... :)

Sunday, March 12, 2017

interesting Talks/Podcasts (March)

From the talks I've heard / seen lately, these are the most interesting:

Development:



Culture and leadership:



In spanish:




Monday, February 27, 2017

Applying the DRY principle

Post previously published in Spanish Aplicación del principio DRY


I always have very clear that in software development is very important to have each business concept in one place only. On the other hand, is also true that the code duplicity is a problem that we should try to avoid or at least limit and remove systematically when needed.

But, sometimes, we follow the DRY principle blindly, without having in mind that each decision have a cost, so I will expose in this post some points that can help us to decide whenever we should remove the duplication or when we can live with it.
  • We should differentiate between duplication of business concepts, rules, validations, flow, etc and duplication at the implementation level (for example source code with small duplication). 
  • The duplicity of business concepts and definition should be avoided as much as possible.
  • Sometimes duplicity at the code level can be a tip saying that there is an abstraction waiting to be discovered, an emergent behavior of the system or a pattern common in our application. Is important to minimize, but it is not a drama if there is "some" amount of duplicity. But be aware that you should be very careful to not generate a premature abstraction. In my experience premature abstractions are much worse than duplicity.
  • If you develop using TDD is better to duplicate code to reach green, and once in green and well covered by the tests, refactor to eliminate the duplication.
  • Depending on the language (C++, python, java...) there are some kind of duplicity that have a high cost of elimination or don't have an idiomatic solution. In these cases we must eliminate duplicity when the result is easier to understand (not only for you, but for the whole team). In the face of doubt, readability must always prevail.
  • It is important to know that when we eliminate duplicity we usually create a common class, a library, a method or any other artifact that allows us to reference / use it from several parts of our code. This is a dependency between the client code and the code to be reused. Dependency is one of the strongest relationships between code and is always an important cost so you should have this in mind when evaluating whether we should eliminate duplicity or not.
  • We should always depend on artifacts that are more stable than ourselves, that is, if we extract common code to a library, but the API of this library changes all the time, this mean that we have created a bad/wrong abstraction and the maintaining cost will increase a lot.

In summary:

  • Is important not to have duplication for business concepts (low level duplicity is less important).
  • We should always evaluate the danger of creating a premature abstraction.
  • We should evaluate the trade offs between the cost of adding a new dependency vs the maintainability cost improvements derived from removing the duplication.
  • If readability is lost by eliminating duplicity, we are doing it wrong.
  • Is better to follow a process of use, use, reuse, and later create the abstraction (instead of directly creating the abstraction).

If you can't afford to wait before creating an abstraction or you can't eliminate/modify the abstraction once you detected that is not the correct one, your problem is that you are generating a great problem and worse complexity than the one generated by leaving a small duplicity.

Although the DRY principle may seem simple to understand, its application, as always in software development, is not simple or systematic.



Sunday, February 26, 2017

More interesting talks (teams, agile, others...)


From the talks I've seen lately, these are the most interesting.