Three insights

Publicado por · Deja un comentario 

I would like to share three insights that have lately become a kind of guiding principles for my work on product/project management on analytics:

  • Make it work, make it right, make it fast
  • Separation of compute and storage
  • Agile is not the same as fast

Make it work, make it right, make it fast

I first knew about this principle in a guide to data science job interviewing. Later on I read about its many interpretations in the mother of all wikis. The meaning for me is as follows.

Firstly write the skeleton of the algorithm, program or thing you are trying to build. Just the basics, with no real functionality, just to ensure that it compiles, runs or executes. Then write the logic in a simple, naive way, but that yields the correct answer. Finally try to improve on speed, space or any other critical performance parameter.

Apart from being in line with the avoidance of premature optimization, this way of operating helps in reducing uncertainty, building confidence, and showing early results.

Separation of compute and storage

Recently I read an ebook titled Creating a Data-Driven Enterprise with DataOps, and this principle appeared in a chapter about Cloud Architecture. Although initially it seemed counterintuitive, the more thought I poured into the concept the more sense it made.

In the cloud, storage and processing are decoupled, and the former is cheap and permanent while the latter is ephemeral and expensive. Compare this to on-premise analytics where both are coupled, permanent and limited.

The impact that this principle has had on me has been profound, even considering how recently I have discovered it, and it has helped me design, implement, and communicate analytical architectures in a convincing manner.

Agile does not mean faster

I have recently discovered the deeply rooted misconception that being agile means giving up on preparation and alignment of stakeholders, and just hoping that every problem will sort out itself during the process of development. This is utterly wrong.

The Agile Manifesto does not mention fast development a single time. Moreover, there are other references that explicitly state that agile does not equate to fast.

In my experience, an agile framework introduces routines and discussion environments where new requirements and feedback from users can be introduced in the scope of the project or product, faults can be detected earlier, and a valid outcome is ready at the end of a sprint. This, however, comes with an associated cost in time and coordination. Agile methods will make reacting to changes easier, but they will not replace preparation before starting a project, and they are not, by any means, an excuse to cherry-picking features to boost in the middle of a sprint for the sake of showing them off in a committee.

In the long run, being agile will mean being faster. This will be caused by hitting the mark more frequently, not by making individual projects faster. As a matter of fact, less projects are expected to be run with a higher level of resources. At the individual project level this is clearly slower and more expensive, but at the project portfolio or the product levels it completely makes sense, if the required time for the methodology to provide results is allowed.


These three insights have become guiding principles in my endeavors in software development, and they help me make decisions and structure my work. I am always open to improve and learn from others, so… what are your guiding principles?

One more visited country

Publicado por · Deja un comentario 

I’m spending Easter in Ireland. One more country visited:

Visited countries

John Cleese on creativity

Publicado por · Deja un comentario 

It was quite some time ago that I first watched this wonderful video, and I have just refreshed the memories of it.

Remember: space, time, time, confidence and 7 coin flips with consecutive heads…

Un año en Aqualogy Business Software

Publicado por · Deja un comentario 

Rápido pasa el tiempo, y ya llevo un año en Aqualogy Business Software. Es una etapa de muchos cambios; veremos lo que está por venir.

How to build a desirable tech product

Publicado por · 1 Comentario 

Original source.

How difficult is to build a real attractive product! Well, how difficult is to build an interesting product. Buff, how difficult is to build just a product… Trying inside a large organization is almost impossible. The pressure to go to the market and ship it as soon as possible. The lack of contact with the end user. The decision process based on multiple assumptions and frequently on a false experience. The product manager role oversized and poorly defined. The PMs used for sales instead of being concentrated in the product…

Definitely, there are many factors playing against most companies’ honourable intention of earning money by selling the best product ever. Their interest is focused in obtaining the maximum results with the minimum investment and risk. This translates into getting the best product out of thin air and inspiration. But this rarely happens nowadays in large organizations. Well, it doesn’t happen unless they implement a clear process, with clear roles and clear functions.

Daniel Cardelús and Pablo Rodríguez present here our idea about how to build a desirable tech product, simply and straight to the point. This is something that large and mid-sized companies can take as a guide to start turning towards success in their product generation process. Or, at least, to check if they are considering all the important factors.