Category Archives: Vision

Against foggy money and the “Cheaper is Good but Expensive can Be Better” Law

Two days ago I wrote about some ugly problems with Glassfish/Weld and I ended up talking about how hard is it to get a good rythm for writing and testing code in a JEE environment.

Time is money. If your train of thought is broken due to delays, then you are wasting even more money than you might think.

Why not spend money in tools to avoid throwing it away in low quality work time? Tools like JRebel. It reloads classes at runtime when you modify them, without requiring that you pack them in jars/wars/ears again and restart the application(s). Almost zero code to deployment time in many cases. Nice!

But there is a problem: money spent in tools or libraries tends to be too solid, and therefore the ones making the purchase decision become a bit too noticeable.

Developers do not use JRebel not because it is not reasonable to do so, but because somebody has to pay with solid money for it. Solid money is money that’s very clearly seen as it dissapears, because there is an invoice backing the expenditure. You can be caught spending solid money.

If we spend 1.000 euros in a tool, we might be seen doing the expenditure. However, if we spend 10.000 euros in wasted time, who the hell is gonna “see” that? This money is foggy money, money that evaporates without a trace.

Not investing in high quality development tools and environments or training is a clear case of cheap is good but expensive is better. It is death by a thousand cuts.

Unfortunately, using bad free but expensive tools & techniques is preferred all too often to using non free but cheap tools & techniques.

Refusing to do what we think is right for fear of finger pointing, all the time, is a proof of lack of maturity, and I doubt great software can be created if worrying and politics take the breath out of you.

It is time for the industry to mature and make a quantum leap towards responsibility, accountability and quality. Time to stop diverting energies away from finger pointing and penny pinching, and to start thinking big & deep.

Because there is no other way to be great!

Just thinking…

‘Debugging the Development Process’ & Timeless Principles

These days I’m re-reading Steve Maguire’s Debugging the Development Process, which is one of the first “realistic development process” books I read, almost two decades ago!

By “realistic” I mean that it takes into account that it is human beings who make software, and that how we communicate and what we feel about ourselves, the team and the process itself is crucial. Processes do not create software: people do. People comes first, processes second; it follows that it is processes that must fit people, not the other way around.

But, back to the book…This book is at least 16 years old, and it shows: no agile-speak here, for example. Yet, this must be the third or fourth time I read it, and the book still feels fresh.

Why is this so? I think that Maguire just keeps pounding on some underlying principles that will always hold, timeless principles that will never change:

  • You must be focused and have a clear purpose.
  • You must be concrete and explicit.
  • You must do things, instead of letting them happen.
  • You must be courageous.
  • You must believe that good enough never is: there’s always a better way.
  • The declared problem tends not to be the real problem: difficult problems tend to be difficult because they are not what they look like, what you are seeing is not what is there.
  • You must care about people: care that is shown via actions, not PR speeches -people almost always resent just-talk-the-talk PR campaigns aimed at them.
  • You must choose the right people/company: you must know your culture and choose the people and companies that are closer to it, because bypassing what’s deeply important to us is very straining, and you just can’t be the best at doing something you don’t believe in.

If you read the book paying attention to this, you will find Maguire provides a thousand concrete policies that work in the right direction to fulfill one or more of these timeless principles. Here are some examples…

Be focused

From chapter 1, Laying the Groundwork:

“Focus on improving the product… any work that does not result in an improved product is potentially wasted or misguided effort”

“The project lead should ruthlessly eliminate any obstacles that keep the developers from the truly important work: improving the product”

“Always determine what you are trying to accomplish, and then find the most efficient and pleasurable way to have your team do it”

“…one way to keep (housekeeping work) to a minimum is to regularly ask the questions ‘what am I ultimately trying to accomplish?’ and ‘How can I keep the benefits of the task yet eliminate the drawbacks?’”

From chapter 3, Of Strategic Importance:

“Don’t waste time on questionable improvement work. Weigh the potential value returned against the time you would have to invest”

From chapter 4, Unbridled Enthusiasm:

“If you hold a meeting that doesn’t end in a decision, that meeting has probably been a waste of time…Try to eliminate unnecessary follow-up work. I think you’ll be surprised at how many follow-up tasks don’t seem nearly as important by the end of the meeting as they did earlier, in the middle of an intense discussion”

From chapter 6, Constant, Unceasing Improvement:

“People often ask for something other than what they really need. Always determine what they are trying to accomplish before dealing with any request”

Be concrete and explicit

From chapter 1:

“At the very least, you should establish a ranking order for these priorities: size, speed, robustness, safety, testability, maintainability, simplicity, reusability, portability…in addition to ranking coding priorities, you should also establish a quality bar for each priority…otherwise, the team will have to waste time rewriting misconceived or substandard code”.

From chapter 2, The Systematic Approach:

“As you put systems in place, explain the purposes behind them so that the development team can understand what aspect of the product the systems are meant to improve”

From chapter 6, Constant, Unceasing Improvement:

“If you want your team members to make great leaps as well as take incremental daily steps to improvement, you must see that they actively pursue the greater goals…let them choose the skills they want to pursue…and merely verify that each goal is worth going after [by making sure] the skill would benefit the programmer, the project, and the company…the goal is achievable within a reasonable time frame…the goal has measurable results…[ideally] the skill will have immediate usefulness to the project”

Be courageous

From chapter 3, Of Strategic Importance:

“Sometimes there are questionable requests…a large corporate client had requested the LAYOFF macro so that they could lay people off without anybody being able to claim that the selections were biased [!]. The company would be in a position to simply point to Excel to prove their innocence…The task fell to me and I refused to implement the request…for months we beat the marketing team’s persistent requests for the feature. Marketing felt they needed the macro to close the sale…”

Care about people

From chapter 6, Constant, Unceasing Improvement:

“If you constantly expose a team member to new tasks that call for new skills, he or she will eventually reach a point at which your project no longer offers room to grow…for the benefit of the company, you should kick such an expert off your team…You have a duty to the programmers and the company to find the programmers positions in which they can grow”

From chapter 8, That Sinking Feeling:

“If your project is slipping, something is wrong. Don’t ignore the causes and demand long hours of the team members. Find and fix the problems”

On and on…

Maguire keeps on adding lots of foolproof advice throughout the book; most of it solidly rooted on the belief that it is people that makes software great -or a mess. I can’t agree more with him!

Yes, Debugging the Development Process is old…so, what? Some principles are timeless, and Maguire knows how to materialize them with concrete policies.

Highly recommended if you care about preserving what’s essential!

No dar la hora, sino hacer relojes

Mirando el título de este blog, Desarrollo de Software “hecho para durar”, no puedo evitar pensar que es un título un tanto largo. Demasiado largo.

Y quizá un punto menos atractivo y más difícil de recordar que Software “hecho para durar”…

Así que varias veces he estado a punto de cambiarlo.

Pero no lo he cambiado, y no creo que lo cambie en el futuro.

Porque lo importante no es hacer Software hecho para durar.

Lo realmente importante es conseguir que sea el propio Desarrollo de Software el que esté hecho para durar.

El software excepcional llegará por sí mismo, si el modo en que llevamos a cabo su desarrollo es excepcional.

Porque, al final del día, es el software el que tiene que ser excepcional: si no lo es, es que la forma en que lo desarrollamos no es suficientemente buena.

Por eso el blog se llama “Desarrollo de Software hecho para durar”.

Porque creo menos en dar la hora que en hacer relojes.

Desarollo de Software “Hecho Para Durar”

Built to Last (“hecho para durar”) es un libro escrito a mediados de los 90. Un libro excepcional por su contenido.

Pero, sobre todo, un libro excepcional por lo que sus autores se propusieron: encontrar “los hábitos comunes a las compañías visionarias…que obtuvieron resultados excepcionales, sostenidos a largo plazo…que mostraron una enorme resistencia y habilidad para resurgir ante condiciones adversas…”

Podéis estar seguro de que algo tan excepcional es algo de lo que yo querría formar parte.

Especialmente en el área que ocupa la mayor parte de mi tiempo, el desarrollo de software, sea como consultor, como responsable de un equipo o como programador.

Resultados sostenidos durante más de 50 años, ¿hay algún programador, responsable de proyecto, jefe de equipo o responsable técnico que no quiera formar parte de algo así?

¿Quién no querría formar parte de un equipo que practique estos hábitos día tras día?

Y, ¿qué empresa no querría ser su cliente?

Ahora bien, lo excepcional no existe en un compartimiento estanco. La excepcionalidad es un modo de ser y estar, una atmósfera.

Debe impregnarlo todo. Empezando por nosotros.

El desarrollo de software es una activad compleja, orgánica, en la que todas las partes interactúan entre sí.

Más aún lo son la creación de un equipo de desarrollo cohesionado y eficaz, o la gestión del propio proceso de desarrollo.

Todo cuenta.

Un programador debe saber cómo escribir código exception-safe, pero también entregar puntualmente. No se puede tener software excepcional sin programadores excepcionales.

Un responsable de proyecto debe tener la capacidad de aceptar que a veces las personas por debajo de él en el escalafón saben más que él en ciertas áreas. Y también debe saber tener un conflicto con el cliente hoy, para no tirar por la borda un proyecto mañana.

O tener una charla seria con un programador que no rinde.  No se puede tener software excepcional sin responsables excepcionales.

La excelencia debe existir a todos los niveles, o no existirá.

La excepcionalidad con excepciones es un contrasentido. Tal cosa no existe.

Todo cuenta.

Este blog se llama Desarrollo de Software Hecho Para Durar porque me gustaría incluir reflexiones, ideas y artículos con la esperanza de que ayuden a crear hábitos excepcionales en el desarrollo,  que perduren.

No solo para desarrollar mejor software (dar la hora), sino para que el propio desarrollo del sofware sea excepcional (dar el reloj).

Para dar ideas y artículos sobre cualquier tema que ayude a obtener un resultado excepcional no importa en qué actividad de todas las necesarias para crear software.

Si creyera que bailar con un hoola-hop nos permitiría obtener un resultado aún mejor, no dudéis que escribiría sobre ello aquí.

No hacerlo no sería profesional.

Y, si alguna de estas páginas está hecha para durar, mejor que mejor.