Saturday, December 30, 2017

"How" vs. "What"

Every year I realize that I am much more interested in how we do things than what we do.

My initial years in this profession I was completely blinded by the kind of things we can do as software developers (sending rockets to space, flying planes, distribute information to the whole planet, creating video games, robotics...).

Despite my passion for technology and the kind of products and solutions, we can create, each day I am more convinced that in our day to day life as developers, the most important thing is how we make things...

  • How we work as a team.
  • How we help others to grow as developers.
  • How we communicate and create together.
  • How we create value for our customers.
  • How we innovate in our processes, relations, learning.


Perhaps, for me is more important the path than the destination, maybe is more important the people than the product.

The funny thing is that, at least in my case, focusing on "how" we should make things, allow me to be involved in the creation of great teams that create great products.

So to evaluate new opportunities, I follow these steps:

  • Evaluate "What" they are doing is compatible with my ethical (See more at my Personal Mission).
  • Second, evaluate "How":
    • They talk about resources and assets or people and skills.
    • They use the values in the hiring process.
    • How they deal with the uncertainty associated with created a new product.
    • They differentiate between outputs and outcomes.
    • They talk about thing to validate or already have all the answer to all question.
    • They have a real collaborative culture or no.
    • ...
In summary, they are optimized to change? or they are tuned to produce in an industrial age that no longer exists?

If we classify the how using the following infographic, I try to identify if they are green or teal or at least if they are open to change.



For me, HOW we work directly affect to my day to day satisfaction, my motivation and my overall performance.

Related stuff:

Saturday, December 09, 2017

"It depends" / Jocelyn Goldfin model for software classification

Continuing with the idea of knowing the context of our software as the first step to making better decisions (see it depends blogpost). I will explain in this post a software classification that I found very useful.


This software classification was created/defined by Jocelyn Goldfin in the article http://firstround.com/review/the-right-way-to-ship-software/ and explained at The "right" way to ship software Jocelyn Goldfein - hack.summit 2016  for example.

The model classifies an application in two axes:

  • Horizontal axis: Stack and deployment model. From very costly to deploy (on-premise, operating systems, embedded software, etc.) to easy to deploy (web application in a cloud PaaS). 

  • Vertical axis:  Business model. From very costly software for a critical mission for an enterprise, up to free software for consumers.


Attending to this classification, we can define the cost of making a mistake for the application, the optimal release process, how to obtain feedback, etc.



For example, for costly enterprise software deployment on-premise, the best approach for obtaining feedback, perhaps is having beta tester programs with discounts for the customer. But to get feedback from a customer-oriented software that is sustained by ads, the fastest way is A/B testing and continuous deployments of new experiments.



Another example, if we consider 1x the cost of making a mistake for a free consumer web application deployed in the cloud, perhaps the cost of making a mistake for expensive enterprise software deployed on-premise may be two orders of magnitude higher.





I found this classification very useful for my day to day work. But remember, the context can be different for each part of a large system and also evolve with time.

According to this classification, these are the systems in which I have been involved:




Thank you, Jocelyn Goldfin, for this useful classification model.

References:



Thursday, December 07, 2017

"It depends" / context on creating software products (I)


"It depends" is the standard consultant answer to any question. It sounds like a joke, but in fact, it is an excellent answer.



If we are involved in creating software products, our day consists of making a lot of decisions. We have to take decisions at very different levels, for various purposes, and with different importance level:

  • Constant micro decisions when developing and designing software (what is the next test? should we remove this duplication? should we divide this class? what is a good name for this method? and for this module? etc.)
  • Constant Architectural decisions about macro design, practices, strategies, etc.
  • Sometimes estimations (or even better, how to split the features into small steps, so we don't need estimations).
  • What are the optimal priorities for the next tasks to accomplish?
  • Wich experiments can we define to validate a hypothesis?
  • Wich technical debt should we pay right now? 
  • etc.

Making decisions is hard, very hard...



In my experience good tactics to make decisions in our profession are:

  • Know as much as possible about the context (business, purpose, why you need to decide about this, etc.).
  • Minimize the risk associated (for example pushing for reversibility when possible).
  • Postpone as much as possible (to gain more awareness about the problem, the context or the risk).
  • Simplify to minimize the number of decisions needed.

And here is the problem. I usually see very little awareness about the context in which we develop the software.

This lack of awareness is why we can waste a considerable amount of energy discussing dynamic typing vs. static typing, optimize runtime performance vs. developer productivity, should we use cloud/containers/microservices.

Everyone is right, or everyone is wrong, depending on our point of view.

If we don't know about the context, the decision is always wrong :)
So "it depends"!!! (on the context)