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 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.


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)