Entre los años 1999 y 2000 me inicie en el mundo del desarrollo de software. Desde esos años vengo escuchando la frase “tirar código”. La misma hace referencia al acto de escribir código fuente o “programar”. No tengo claro de dónde viene la frase, ya que en el idioma Ingles (lingua franca de la Ingeniería de Software), se utilizan las frases “to code”, “to write code”, las cuales podrían traducirse como “codificar” (programar) y “escribir código”.

“Tirar código” es una frase común entre profesionales de distintas edades, se la he escuchado a personas nacidas en los 60 y llegando hasta el 2000. Un día, reflexionando sobre temas de calidad del software y mejores prácticas, me llego a la mente la frase y de pronto sonó inapropiada. En la República Dominicana cuando algo o alguien es “tirado” (adjetivo) tiene una connotación negativa: descuidado. “Pedro trabaja todo tirado”, o su versión más coloquial “Pedro trabaja to’ tira’o”, significa “Pedro es poco profesional o descuidado, no pone atención en los detalles”.

Anoche mientras le hacia la observación, repetida en muchos círculos, a un grupo de estudiantes universitarios de que cambien la frase “tirar código” por “escribir código”; me puse a pensar sobre cuales podrían ser los orígenes de la frase. Realmente me da mucha curiosidad el saber

¿Cómo pasamos de “to code / to write code” a “tirar código”?

Si alguien tiene, o cree tener, la respuesta o una idea favor escribir en los comentarios.

How to buy fruits?

When I was a child, I spent a lot of time with my grandmother. She was raised in a remote agriculture community of my country. So she was very experienced with agriculture products. I love fruit juices and she love to consent all her grandchildren. One of the earlier lessons that I learned was how to pick a good, ready to eat, fruit. There were “easy” ones, like mangoes. Even a child can tell when a mango is not ready to eat yet, ripe, or overripe. But I also face more difficult challenges like melons and passion fruits.

Those two have a similar little trick, as my grandmother teach me. You have to evaluate the outer layer, or skin, and look for overripe signs. If the outer layer was looks ripe, but firm, then you have to evaluate the inside of the fruit, without open it. Here comes the trick: you must shake the fruit near one of your ears and try to “listen” for the seeds to bounce and hit the inner cavity. If you feel or hear the seeds bouncing then there are good chances that the fruit was ready to eat.

You must have similar stories with culture and region specifics variations. There are other kind of “passed-on” skills like how to buy the best used car with a limited budget.

Now you could be a ground-up woman or man. You may be a c-level executive, a manager or any organizational role facing the decision of buy software products and / or services. And here comes the question: Do you know how to buy a software that is just “ready to eat”?

How to buy software?

Unfortunately, our elders did not taught us how to buy a good piece of software: a “healthy” one. Now we are facing that problem, and each day it becomes bigger and bigger. The average executive does not know how to evaluate the quality attributes of a software product. The more versed ones only know how to ask for aesthetics (visual), usability (easy to use, responsiveness, etc.), and functional quality. So they know how to assess if a software is “easy to use”, “looks pretty” (as of the industry and user-base standards), and if presents the functional characteristics they need (modules, features, etc.).

But there are other quality characteristics of a software products less obvious to the end user. To keep this discussion out of the technical (software engineering) jargon, just imagine (as with the fruits), that software products have an “inside” meat, that needs to be assessed as well. This quality characteristics of the “inside” parts of the software are called Structural Quality Characteristics.

So, if you are not versed on how to evaluate the “insides” (structural quality) of a software product, do not worry. There are quantitative evaluations and even standards that can throw light into this matter. The last question will be: How to connect all this with my reality?

What to do?

Let’s say that you are a COO (Chief Operations Officers), or a CFO (Chief Financial Officers); and you are involved in a big project requiring the purchase of a very expensive software product. If you are not in a very specialized industry, there will be lots, or at least two, options. So you need to select the “mature” (not the green, or rotten) one. And remember that “mature” means “good in the outside and in the inside”. Here you need to ask for the experts.

Your due diligence should be to demand that your IT staff, external organization, or an individual consultant bring together an assessment process that translate all this stuff into a simple, quantitative, decision matrix.

After a quick poll ( https://plus.google.com/+LorenzoSolano/posts/U6ZSU5t22vA ), asking about the relation between Story Points and Business Value, I want talk about this misconception.

Quick Definitions (context: Agile, Scrum, Software Development)

[Delivered] Business Value

Increase on certain aspect of an organization, due to a change on some software product. That aspect could be a revenue stream, risk mitigation, etc.

In simple words, the delivered business value after an iteration / sprint is the increase on the business’s capacity to generate more money or to avoid certain losses (financial, reputational, etc.)

Story Points

The perceived amount of effort, for a development team, required to build certain feature into a software system.

The main concepts here are: perceived, and a [specific] development team. What this means is that the effort is subjective measurement, and that the “subject” on software team in the entire universe. You cannot compare on team to another in terms of how much Story Points (effort) they assign to a given feature to be built.

Story Points and Business Value are Unrelated

Scenario

Image two software development teams given the task estimate how much effort (not hours / time, not money), they as a team, will require to build the Feature X. Both teams have the exact same context (imaginary of course): they belong to the same organization, respond to the same stakeholders, work with the same technology stack, and with the same tools.

Where they differ is in their seniority (experience) level. So, we have a Beginner’s Team and a Senior’s Team. If you ask the beginners about the effort required to build Feature X, they will respond with an estimate much larger than the seniors.

For the point of view of the business owner, the value added to the organization by the Feature X (after construction), is the same. They just want the new functionality, no matter how hard or easy is for the builders to do it.

In a, less abstract, example; think of the amount of business value added by the Feature X, as a litter of fresh water in the desert. Imagine your family lives one mile away from the water well,

and that you need to get that litter of water to cook the day’s meals. That’s your business value, you just need the water no matter how you get it.

Now comes the effort: if you must go by foot and bring the water to your house the effort required will be high.

But if you use a camel to go and get the water, the task becomes a little easy.

Conclusions

From this, inadequate, comparison I want to point out some key takeaways:

• Do not compare teams per their average velocity (Story Points per Sprint)
• Do not assume that one team is delivering more business value because they have a higher “velocity” that another
• A team’s velocity is for their usage only
• You can compare past to actual velocity, analyze trends, and respond to abrupt changes on velocity (up or down) as an indicator that something is happening: new members, rotation, infrastructure / technology stack changes, etc. Obviously, the comparison will be between measurements of the SAME TEAM, past and present.

“Good” programmers are like cats. They are experts in a subject matter with a narrow vision. When cats are hunting (programming) they abstract so much of the task that they risk getting involved in dangerous situations. They climb too high or forget about natural environmental dangers. Maybe that’s why big cats almost always hunt in groups, with specific roles. At the end of the day (domestic) cats will hunt but with a high risk of get killed or seriously injured.

Most programmers act like cats, and their “prey” is to implement some functionality, usually with a very hard time constraint along with functional and performance expectations. That “prey” is marked (pointed to) by its manager. In that path they get into dangerous positions, and just like cats, they leave a messy code-base reducing the internal (structural) quality of the product.

Who’s responsible?

The Software Engineer

Some junior, or naïve, software developer can think that the only measure of quality is the functional one. Or they are young enough to never have to maintain a dirty (impossible to maintain) code base. But, as cats, they will only see the prey pointed by their manager or client. It can be a matter of the level of professionalism but if they are not required to write good, maintainable, code, then almost always they won’t.

On the other hand, we have the “crazy scientists” culture saying: “The best developers are mad scientist”. They are disorganized, un-ruled, bad team members, and fast builders.

The Client

Early in my career, I used to think that clients were guilty for not caring about the product (code) quality. They always want faster and cheaper development without thinking about the implications.

Let’s face it, clients will be clients. They only mind their own business. They want our software products to support their processes. And because an industrial mindset, they think that software maintenance is as simple as changing a defective machinery.

Bottom line: stop blaming your client for the lack of quality, look in another direction.

The Manager / CEO / CIO

You have to understand your business. If you are building software and you don’t think that the code (internal) quality is important for your business, better start selling vacuums. If you focus your company and teams only around functional quality and super-fast development you are digging your own grave. In the near future the maintenance cost will drain all your revenues, will demoralize your teams and make your clients angry. If you are lucky enough, your employees and clients will leave you, without any legal implications.

Your clients don’t know anything about software. They’re only interested on the functional quality, and very few of them in performance and security issues. It is your job to create software that meet both the client’s imperative (functional quality), and your business needs (structural quality). You have to mark the target so your cats will get the right prey.

A tool to train your cats: Better Code Hub (https://bettercodehub.com)

The Better Code Hub is a tool to check your code for structural quality issues. It helps you by checking a public GitHub project against a set of ten simple rules:

1. Write Short Units of Code
2. Write Simple Units of Code
3. Write Code Once
4. Keep Unit Interfaces Small
5. Separate Concerns in Modules
6. Couple Architecture Components Loosely
7. Keep Architecture Components Balanced
8. Keep Your Codebase Small
9. Automate Tests
10. Write Clean Code

For small projects it run the analysis in less than a minute. After that, you can check the results and improvement suggestions if you violate some of the principles.

Usage

The landing page shows you a grid with all your projects and last analysis summary. Each grid item has ten icons representing the principles above. If they are green you have no problem, if any is not green you can click and see more details about violations.

To start you have to do only a few simple steps:
1. Select the project you want to check and click “Analyze”

2. Wait for the analysis to complete
3. When done, the page will redirect you to the details page

First (prev. image), it will show a summary indicating if some principles have violations. If you click on one, you’ll see the details.

Seeing past results

For already analyzed projects when you want to see again the details of the last analysis just click the “View Results” icon.

Closing thoughts

Managers and developers should seek to improve the structural quality of the product. Clients, especially those outside the software industry, do not care about internal quality. Is our task to seek efficient formulas to run our business in such a way that we can deliver both functional and structural quality ensuring a good profit on the long term. With tools like the Better Code Hub we are a little closer to that goal.

Code Quality: Human variables in the equation was originally published in Write BetterCode on Medium, where people are continuing the conversation by highlighting and responding to this story.