Amazing. Every word of what you just said was wrong. The Rebellion is reborn today. The war is just beginning. And I will not be the last Jedi. - Luke Skywalker

I am sure that most of you reading here can give this description when asked about “how do you organize your development process”:

Well, we do Scrum because we are Agile. We estimate the most important stories to know how much work can be done during the sprint. Then we start developing. Each developer takes a story and creates a branch on top of the development branch. When the task is done, the developer creates a pull request and the code is reviewed by the team. If everything is ok, the code is merged into the development branch. When the development branch is ready, we merge it into the master branch and deploy it to production.

First mistake: “We do Scrum because we are Agile”

Scrum is not Agile. Agile is Agile. Scrum is a wrapper to make XP (extreme programming) “more palatable to management”

Second mistake : “We estimate the most important stories to know how much work can be done during the sprint”

Importance comes from value. Priority should come from cross-matching value and effort. Max value, min effort: that’s the top priority. As nobody will tell you how many monetary units you will receive from a completed story, estimating the effort is just a waste of time.

Discuss about the most relevant topics regarding your product/service. You need some rough estimation as a team to bet on what should be done first, but do not let the estimation be the main driver of your development.

Third mistake: “Each developer takes a story”

Then you get Bob, who knows about the frontend. Then, Alice, who only knows about the API. And Ron, who nobody knows what he knows about, but he is the only one who knows how to deploy the application for some reason.

Tackle stories as a team from definition to production.

Fourth mistake: Doing Gitflow

This is not literal from the explanation but it is “common sense” nowadays in many organizations and teams.

Atlassian itself has stated that GITFLOW IS OUTDATED. As they state here: “Gitflow is a legacy Git workflow”

Stop doing Gitflow and start doing trunk-based development with feature flags or some similar mechanism. Happiness will come to your team.

This post is part of a series. Read the next part here

There are thousands of articles about how to use ChatGPT, why it is cool, how astonishing it is. I do not care about that in the context of this post. Even if ChatGPT was the best tool ever to generate text/code, I am listing here three cases where I think it is not a good idea.

Disclaimer: my goal is not to point to this or that product and say how bad it is. I am not providing any links to any product, even when I have seen them and tested some of them.

ChatGPT to generate commit messages

It seems natural: you take the diff between two code commits and infer the commit message from it. It is so straightforward that it must be a good idea. But it is not.

Commit messages are intended to provide a human-readable description of the changes. They are written by humans for humans so the intention of the changes is clear.

You cannot know the intention of the changes from a diff. The diff is the how of the changes, not the why.

“But Dani, people write terrible commit messages. Let’s use ChatGPT to generate them!” I agree that some people write terrible commit messages. That is a reason to train them; not to let a machine write terrible commit messages.

There are really nice templates for commit messages. There are conventions and there are tons of articles explaining how to write good commit messages (a nice starting point is here).

“But Dani, some commits need a nice summary of what has been done because they have many changes.” Ok. Am I the only one who clearly sees that the problem here is the commit size, not the commit message?

ChatGPT to generate changelogs

This is very similar to the previous case. There are already tools that generate changelogs from the git history. I never liked this idea (well… not “never”, I advocated for it some years ago…) as people tend to use it as a black box and copy/paste the output to whatever changelog database they use. Even worse, some people generate release notes this way.

You could argue that, if you put such information in the commits, this process becomes really trivial but I can think of many commit messages that are not related to customer facing changes (i.e. “Refactor to improve readability of X class”, “Fix bug in Y method”, “Add unit tests for Z class to cover R case”).

Again, changelogs are meant to be read by humans and should contain information about the intention of the changes. You cannot know the intention of the changes from the code.

Imagine generating commit messages from the diff using a machine learning model and using those commit messages to generate a changelog and/or a release note. You would end up with the ilusion of having proper documents and would probably have to spend a lot of time fixing them.

ChatGPT to generate tests

This one is my favourite. I recently saw this tool that promotes itself showing some source code and the generated unit tests for it.

Aside from violating TDD principles (you could generate extra tests aside from the ones you use to design but no the whole test suite), it violated basic testing principlies such as unit testing private methods and testing implementation details.

Even more: the example they show does not even run because it lacks imports. And, if you fix the imports, tests don’t pass.

Could you generate tests properly from the code? I am pretty sure you can if you rely on some static analysis prior to the machine learning model to generate code that looks like tests that pass by executing your code. I mean… I have done it without ML in the past. In fact, I generated test templates with known assertions as I was doing a code generation tool for a specific domain. Those tests were meant to check that developers using the code were using the API correctly.

Is this desirable as a generic tool? I do not think so. This conflicts with proper TDD as it masks the need to make tests first. I am not going to argue here about TDD being the right way to go or not: latest studies say that using TDD along with other techniques is a good predictor of success in average, but you are free to test however you prefer. Just don’t use ChatGPT to generate the tests :)

Do you know what would be awesome? A tool that generates code from TDD tests. That I would like to see.

tl;dr: Every project I have seen in outsourcing companies has a budget. But having a classic budget is not agile. It’s a static document that is not updated during the project. This is a draft of one of the potential solutions to this problem.

How can we translate agility into budgeting?

Let’s say you have a nice self-managed team that adapts and delivers value at a fast pace to a costumer of a given service-provider company. You have achieved the Agile nirvana. Haven’t you?

There was some bargaining between the service-provider and the costumer, and a budget was agreed upon, along with some broad scope and some high-level requirements to be delivered at a certain deadline.

Problems appear when budget seems not to be enough and/or deadline is coming and the customer is not satisfied with the whatever the team has delivered.

Problems also appear then the customer’s context changes so wildly that the original scope is no longer valid at all.

Problems also appear when the team is delivering but the customer feels that something is off. The team is not to blame, but the customer is not satisfied.

Should we keep the project going? Is the customer going to lose 100% of the budget regardless of the outcome? Is the provider going to lose 100% of the expected income plus the opportunity cost of blocking the team for a while?

I will explore here a potential solution to these problems. But first we need to define some constraints.

Hypothesis

There is a way to fairly balance the spent budget up to a certain point, the savings of the customer and the compensation to the provider if any party decides to retire from the project before the deadline.

This proposal brings an equilibrium point between the customer’s and the provider’s interests. None of them will regret this agreement once the project starts in any reasonable scenario.

Necessary conditions

• Customer trusts the team
• Customer will prefer a viable product over a perfect one if that means:
  • The product is delivered before the deadline
  • The product is delivered for less money than the maximum budget
• Customer assumes that the scope will change as both them and the team learn more about what adds value and what doesn’t
• Provider is commited to educate the customer about the agile process
• Provider tries to minimize waste and maximize value per unit of time
• Provider has a queue of projects to work on and/or values the importance of free earned time
• Customer and provider assume that the context when starting a project will change during the execution of it and nobody should be blamed for that nor charged.

The model

The model is concentrated into a single function that defines the balance between the customer’s and the provider’s interests at any given moment and how money and time are balanced.

I named it the Agile Budget Split Function, and it depends on the elapsed time.

This function is defined at company, department or project level. It’s a function that is defined by the company’s culture and the team’s values.

This function must be easy to understand and easy to explain to the customer. It must be easy to explain to the team as well.

In the next article I explain the basic theory behind the model and I give a concrete example, using a constant function.

DISCLAIMER: This is a WIP

This is the second part of a series of posts about agile budgeting. The first part can be found here.

Agile Budget Split Function \(ABSF(t')\)

As I mentioned in the previous part, this is the function that condenses all the model. It’s shape defines the balance between the customer’s and the provider’s interests at any given moment and how money and time are balanced.

Given that:

• Project has a maximum budget \(B\)
• Project has a maximum duration \(D_B\)
• Elapsed time at a given moment is \(t\).
• Normalized time is \(t'=t/D_B\) with \(t'\in[0,1]\)
  • \(t'=0\) means that the project has just started
  • \(t'=1\) means that the project has reached the deadline
• Remaining budget at a given moment is \(B_R(t')=B-(B/D)·t=B(1-t/D) = B(1-t')\)

Then, we can split the remaining budget in two parts if the project stops at a given moment \(t'\):

• \(ABSF(t')\in[0,1]\) is the split factor function.
  • It represents what percentage of the remaining budget is saved by the customer if they retire at a given moment \(t'\).
  • \(S_\$(t') = B_R(t')·ABSF(t')\) are the economic savings for the customer
  • \(C_\$(t') = B_R(t')·(1-ABSF(t'))\) is the economic compensation for the future blocked time (opportunity cost)
  • So, the remaining budget is the sum of both savings plus compensation: \(B_R(t') = S_\$ + C_\$\)

Additional results

• \(T_S(t') = (1-t')\) is the normalized saved time for both parties

  Each party saves time, but the model does not evaluate how this time is used nor quantifies it in terms of money. This could translate into a marketing advantage for the customer and room for other projects or free time for the provider.

• Provider income: \(P_\$(t')=(B*t'+C_\$(t'))=...=B(1-ABSF(t')·T_S(t')) < B\)
  • This amount is never bigger than the maximum budget.
  • If \(ABSF(t') = 0\), the customer has no savings and the provider gets the full budget. (See the example about the Predatory Provider in the next post)
  • If \(T_S(t') = 0\), it means that project reached its end exactly at the predicted maximum deadline, spending all the budget.

Constant model

As an example, we can assume that the split function a fixed percentage, so that \(ABSF(t') = ABSF_0\), where \(ABSF_0\) is the constant.

This means that the customer will save the same percentage of the remaining budget at any point in time and this amount will be also the compensation for the blocked time.

For example, imagine we settle a project with these parameters:

• Max budget: \(B=400000\)
• Max duration: \(D_B=10\)months
• Let’s give some room to the customer: \(ABSF(t') = ABSF_0 = 0.8\)

Imagine that something happens because things happen and the customer wants out at \(t'=0.5\) (half of the project duration).

Then:

• \(B_R(0.5) = B·(1-0.5) = B·(0.5) = 200000\) has not been spent yet.
• \(S_\$(0.5) = B_R(0.5)·ABSF = 200000·0.8 = 160000\) are the economic savings for the customer
• \(C_\$(0.5) = B_R(0.5)·(1-ABSF) = 200000·0.2 = 40000\) is the economic compensation for the blocked time (opportunity cost)
• \(P_\$(0.5) = (B·t'+C_\$(0.5)) = (400000·0.5+40000) = 240000\) is the provider income
• \(T_S(0.5) = (1-t') = (1-0.5) = 0.5\) is the normalized saved time for both parties, which corresponds with 5 months.

Is the constant model useful?

I find this model too simple but it is an applied example about how to apply the principles. It is easy to understand and it is easy to calculate.

Maybe some ABSF in a sigmoid shape could be interesting. Something to protect the customer from poor value deliveries in the first stages and to protect the provider from the customer’s whims once the project is mature. Maybe some “tunable” sigmoid like these could be interesting.

Integrating this model in your business as a software provider

• Project can be negotiated as a regular waterfall project in terms of budget and deadline limitations, but these are just boundary conditions (maximums), not mandatory limits that must be reached.
  • This helps the sales team to sell the project using their regular sales pitch with some variation.
  • This helps the customer to understand the project in terms of their regular project management.

• The development will follow an iterative process where the customer must be an active part, providing feedback about value provided.

• All split conditions for the remaining budget are known and agreed upon by both parties. No surprises. No bargaining post-kickoff.

• If the feedback is bad during the early stages of the development, customer can retire saving most of the remaining budget, but not all of it. The team will be compensated for the work done and the blocked time (opportunity cost).
  • The earlier the customer retires, the more money they save but the less value they get.

• If the feedback is good during the development, the development will reach some point where the customer will decide that there is no more value to be added before reaching the deadline and the project can be considered done.

  • In this case, the customer can save part of the remaining budget, but not all of it. The team will be compensated for early delivery of the highest possible value.
  • The customer gets top-value in less time for less money.
  • The team gets higher compensation/effort ratio, plus more time to work on other projects (or to rest).

In the next article I show some Q&A and degenerated cases to get some perspective.

DISCLAIMER: This is a WIP

This is the third and last part of a series of posts about agile budgeting. The first part with the basics can be found here and the second (with the mathematical theory) here.

Some questions

What happens if “project is about to reach deadline and customer is not satisfied with the value delivered”?

That scenario means that the agile process is not working in this project. Not meeting a deadline is something that can be predicted and avoided given the constraints I provided above.

I am not saying that this is not a real problem, I just say that it does not apply to this proposal in its current form.

Why not predate the budget with a draconian contract?

Because our work is to deliver value, not to pay lawyers to write smart contracts. If you prefer to predate the budget in case of early retirement, go ahead. But then you are not in the software business, you are in the legal business.

This is a suboptimal solution as delivering value way before the deadline has more direct and potential income.

How the hell are you going to explain this to the customer?

First condition: the customer must trust the team. If the customer does not trust the team, then this proposal is not going to work.

Also, define a \(ABSF(t')\) that is easy to explain. Maybe a constant is good enough. This is a business decision.

Degenerate cases

Provider predatory model

In this model we rely on lawyers to write a contract where, once it is signed, the customer is punished if they decide to retire early. This is a very bad idea, but it is a model that exists in the real world. I just want to express it in terms of the previous equations.

In this case, as the customer has to spend the whole budget in any case, the project will go on until the deadline, no matter what. Trust is destroyed in this kind of scenario, IMHO.

As there is no trust, any attempt to deliver value early will be translated into artificial work that will not add value to the customer. This is a waste of time and money for everybody.

• \(ABSF(t') = 0\), provider predates the budget excess
• \(S_\$(t') = 0\), no savings in the budget
• \(C_\$(t') = B_R(t') = B(1-t')\), but this will eventually be zero as \(t'=1\) because of artificially extended delivery time.
• \(T_S(t') = 0\), no savings in time

Customer predatory model

In this model the provider is not compensated for the blocked time if the customer decides to retire early.

• \(ABSF(t') = 1\), customer predates the budget excess
• \(C_\$(t') = 0\), no compensation for the opportunity cost
• \(S_\$(t') = B_R(t') = B(1-t')\), all savings in the budget
• \(T_S(t') = 0\), no savings in time

In this scenario the customer has all power. They can retire at any time and save all the remaining budget. The provider will not be compensated for the blocked time, but they will be compensated for the work done.

Anyhow, under this constraints there is no benefit on delivering early, so the provider will keep value hostage to ensure the next payment. This is a waste of time and money for everybody. Again.

A really good talk about this

Here you have a talk from AgileIndia 2015 by Evan Leybourn about managing Agile projects. It is worth watching. A couple of times.

TODO (for the series)

• Add all examples
• Add references
• Add plots
• Spanish translation
• Add LaTeX support

Disclaimer: Si vienes buscando nombres de lenguajes, frameworks, herramientas, etc., no vas a encontrarlos aquí. También ten en cuenta que el contexto de este artículo es el de alguien desarrollando software viviendo en España en el año 2022; puede que lo que escribo no sea aplicable a tu contexto por muchos motivos.

No es un lenguaje de programación

Podría poner enlaces aquí a artículos sobre tendencias en la industria o sobre lenguajes que están de moda, pero no lo voy a hacer. Los lenguajes van y vienen y, sobre todo, tienen características que los hacen más o menos adecuados a diferentes proyectos.

En tu carrera profesional seguramente transicionarás entre varios lenguajes (o versiones del mismo). Si bien esto te va a facilitar el encontrar trabajo, no es lo que te va a permitir ganar dinero de verdad.

No es un framework

Los frameworks son herramientas que te permiten, supuestamente, construir software más rápido. De hecho, muchas veces la popularidad de un lenguaje va ligada a la popularidad de un framework (Ruby/RoR, os estoy mirando a vosotros).

De nuevo, el saber de un framework seguramente te abra puertas (a la vez que te cierra otras, por cierto), pero ganar dinero de verdad va de otra cosa.

¿Qué es lo que te va a permitir ganar dinero de verdad?

Pues para quién lo vive ya, es evidente. Y para las madres de los 80/90, también. El mundo está virando en otras direcciones, pero a día de hoy lo que marca la diferencia es SER CAPAZ DE MANTENER UNA COMUNICACIÓN FLUIDA EN INGLÉS SIN MIEDO; TANTO HABLANDO COMO POR ESCRITO.

Hala. Ya soy tu abuela.

La diferenciación

A pesar de vivir rodeados de cultura anglosajona, con capacidad de consumir miles de piezas de entretenimiento en inglés, viviendo en un mundo tecnológico que se mueve en inglés, el porcentaje de gente que se siente cómoda viviendo en inglés a diario es bastante bajo.

Creo recordar algo como que del 30% de gente que habla inglés, sólo el 20% considera que lo hace con nivel alto. Eso es un 6% en la población general. Teniendo en cuenta que el nivel de inglés correla bastante bien con el nivel de estudios y que en nuestro sector abunda el nivel alto de estudios, igual podemos subir el porcentaje a un 10% de la población en el sector para hacernos una idea.

Resulta que tras décadas de tener el inglés por todos lados, el dominarlo a nivel medio es algo que te hace destacar del resto.

A qué me refiero con “de verdad”

A día de hoy, todavía encuentro ofertas para “juniors” pagando en torno a 25K€/año. Teniendo en cuenta lo que una empresa suele ganar con el trabajo de cualquier trabajador, sobre todo en el sector tecnológico, es una cantidad ridícula.

Luego está el problema del techo. Por mucha experiencia que acumules y mucha responsabilidad que asumas, parece que hay un techo entre los 60k y los 80k si buscas en empresas netamente españolas (y en bastantes extranjeras, no voy a mentir).

Puede parecer que esas cantidades están muy bien… y lo están dado el contexto, pero el potencial de ganar mucho más es muy alto en cuanto te mueves a empresas de producto propio (o startups) extranjeras; sobre todo en USA.

Hablamos de salarios de 100k, 150k, 200k, 300k, 400k, 500k… y más. Y no hablo de CEOs, hablo de gente que hace código.

Según datos de levels.fyi:

En realidad no basta con el idioma

El idioma es barrera de entrada pero también hay que saber hacer las cosas. Cuanto más subes de salario, más competitiva está la cosa en general (aunque hay empresas donde esta presión es menor). Te vas a encontrar con gente top de la industria, con mucha experiencia y, posiblemente, nativos. También hay gente paquete, pero mejor pensar que vas a una liga superior de entrada.

Hay también un componente muy importante de seguridad en ti. Muchas veces nos cuesta aprovechar una oportunidad para cambiar de puesto de trabajo, incluso en nuestro propio idioma, porque es muy difícil romper la inercia de estar en un sitio que ya conoces y que te da de comer aunque tenga sus problemas.

Si ya es difícil así, súmale el tener que hablar otro idioma. Y súmale, en muchos casos, una componente importante de síndrome del impostor. Cuando ves las diferencias salariales entre un perfil junior en inglés y un perfil senior en español, es fácil caer en la tentación de pensar que no eres lo suficientemente bueno para trabajar en inglés.

Ahí es donde entra la segunda parte del asunto: sin miedo. La confianza viene con la práctica, así que a lo mejor interesa practicar más inglés y menos React, porque el tiempo es finito y no puedes hacerlo todo.

Y, ¿en el futuro?

Hay quién dice que deberíamos aprender chino mandarín. Hay quién dice que con el español no hay problema, sobre todo viendo la tendencia en USA. Hay quién dice que el inglés va a desaparecer y que el futuro es el español.

Yo lo que sé es que un cambio cultural tan grande como desplazar la lengua hegemónica en la industria no sucede en 1, 2 o 10 años. Bueno, en 10 a lo mejor. Pero en el peor caso has usado esos 10 años a su máximo potencial y has podido ganar dinero de verdad a la vez que te has preparado para el futuro.

Cómo aprendí yo

Como no soy nadie para decirte como debes aprender con tus circunstancias, me limito a comentar como me fue a mí.

A mí me funcionó una mezcla entre ir a EGB/BUP/COU y tener mucho ocio en inglés sin alternativa en español. Especialmente videojuegos, música, libros, comics… El querer disfrutar de estas obras me creó un interés desmedido por aprender el idioma.

Esto era todo consumo pásivo en su mayor parte; no empecé a hablar a diario hasta que me mudé a Alemania (donde, además, aprendí alemán).

Hay un componente muy relevante social en todo esto. Si eres de perfil tímido o introvertido, seguramente debas poner más de tu parte para encontrar tu ambiente adecuado donde practicar inglés y este tipo de perfiles es bastante común en nuestra industria.

Yo, entre que soy bastante introvertido y que acabé harto de ir a clases en mis años de universidad, siempre he tenido una vertiente muy autodidacta. Si te funciona, pues es una opción. O tira de apps, podcasts, libros, cursos reglados, etc.

tl;dr: Instead of reading code or inserting “temporary” code, learn to debug. Debugging allows you to see the actual values of variables and how the execution jumps from one line to another. Nowadays, most IDEs have built-in solutions for most common languages, so you don’t even need to be an expert: with just a bit of basic knowledge you’ll be able to debug your code.

Do you see yourself in any of these situations?

• You get a legacy codebase and you have to make changes to it. It has no tests and no docs. You need to understand it fast. You then try to read the code and run it to see what it does, maybe printing some stuff to console. After 2 weeks, you decide to run to the hills and retire from software development forever.

• You have a fancy project composed of multiple interconnected sub-systems/components/whatever you call them. You need to make a change in one of them, but you don’t know how it will affect the rest of the system. Luckily, you have tests in place! But these tests require a lot of configuration that is not documented. You spend 2 days trying to get the tests to run, and then you realize that they don’t even cover the part of the system you need to change. You decide to run to the hills and retire from software development forever.

• You have a bug in your code. You try to fix it, but you can’t reproduce it. You try to add some logging to see what’s going on, but you can’t reproduce it. You try to add some “temporary” code to see what’s going on, but you can’t reproduce it. You decide to run to the hills and retire from software development forever.

If your answer was “yes”…

Then you will be a much happier person once you learn how to use a debugger.

Debuggers are tools that allow you to inspect the state of your program while it’s running. They allow you to set breakpoints, which are points in your code where the program will stop and allow you to inspect the state of the program. You can then step through the code, line by line, and inspect the state of the program at each step. You can also inspect the state of variables, call functions, etc.

• Debuggers are non-intrusive: they don’t modify your code in any way. They just allow you to inspect the state of your program while it’s running.
• You can debug your tests. If some test suddendly fails, you can debug it to see what’s going on (some people could argue that this smells like a bad test because it cannot be “easily understood”, but that’s a different topic).

But debugging is hard!

Debugging is not hard; using ugly or complicated tools is hard. There is a lot of discussion about “how unfriendly gdb is”, but aside from these debates in the C/C++ world, debugging most of the code out there is quite easy and straightforward nowadays most of the time.

Debugging Python, Javascript, Typescript, Java, C#, etc. (which represent around the 70% up to 90% of the code out there depending on the source you check) is nowadays fully supported by the IDEs and editors you use. You don’t need to learn a new tool, you just need to learn how to use the one you already have.

Some authoritative example

Here you have John Carmack talking about IDEs and tools.

He’s the creator of Doom, Quake, Wolfenstein 3D, and many other games. He’s also a very good programmer. He’s talking about how he uses the debugger to understand the code he’s reading.

TODO

• Add example
• Add references to pros and cons