We solve problems

  • High quality tailor-made software
  • Training courses on TDD, BDD, clean code, and refactoring
  • Consultancy and guidance
  • Help teams reach the next level in quality and productivity

Archive for the ‘Agile’ Category



Este post habla de dos de los valores de XP: Simplicidad y Feedback. Fundamentales y habitualmente olvidados.

Cuando escribimos software o dibujamos una interfaz de usuario, estamos dando forma a una solución concreta de las muchas que puede tener un problema. Al elegir una solución automaticamente descartamos las demás porque nunca damos marcha atrás para escribir otra solución distinta si la que tenemos ya “funciona”. Por esto hay que reflexionar constantemente sobre la complejidad de la solución que hemos elegido. Lo mejor es hablarlo con los compañeros, discutirlo. A menudo exponiendo la idea descubrimos que podemos conseguir lo mismo de una manera más sencilla.

La clave para poder simplificar es tener en cuenta cuál es el objetivo (qué problema fundamental estamos resolviendo) de negocio. Pero no el objetivo del software a largo plazo sino de la release actual. Lanzamos releases frecuentes en ciclos cortos para obtener feedback y cada una tiene el objetivo de aprender algo concreto del negocio o de los usuarios. Cada release ofrece alguna caracteristica nueva o un cambio que les ayude en su día a día pero sin querer abarcar demasiado de un golpe. Me gusta que la lista de features y cambios de una release me quepa en la cabeza, que pueda contar con los dedos de una mano sin necesidad de documentos. Y que haya un objetivo predominante.

Para simplificar hay que tener en mente cuál es el objetivo de la release actual, que no es el mismo que la release que haremos dentro de 3 meses. De aquí a 3 meses habremos cambiado buena parte del código, a veces mediante refactoring y a veces porque nos damos cuenta de que hay otras necesidades. La vida cambia en 3 meses y en menos.

Conviene darle más de una vuelta a la solución, hay que “resimplificar” todo lo posible. Lleva poco tiempo hacerlo y tiene un beneficio muy grande en el medio y largo plazo. "Vale ya funciona, ahora vamos a echarle una pensada para ver si lo podemos simplificar, a ver si podemos borrar la mitad del codigo y que siga funcionando".

El código tiene que quedar fácil de entender y su simplicidad es más importante que el uso de patrones. No tenemos por qué aplicar el patrón MVVM en absolutamente todas las partes de la capa de presentación, a veces su complejidad no se justifica. Por cierto, recordemos que un ViewModel es una representación de la vista y no un DTO, un ViewModel es una especie de "controller".

La soluciones deben ser lo más abiertas posibles para poder dar margen de maniobra al usuario y aprender cual es su forma preferida de trabajar. Hay que identificar limitaciones innecesarias que estemos introduciendo tanto a traves de al interfaz de usuario como a nivel del código para poder evitarlas. Una solución abierta se centra en el problema a resolver, en el “qué” y permite cambios de forma con facilidad, poder pivotar hacia otras cosas.

Por ejemplo, imaginemos que hay 3 acciones fundamentales que el usuario puede realizar en la aplicación. No hace falta que las realice en un orden concreto, el objetivo de negocio es que pueda realizar las acciones A, B y C cuando mejor le convenga. Entonces no hagamos que para ejecutar la acción A, tenga que hacer primero la B. Eso es introducir una limitación innecesaria.

Ahora un ejemplo de complejidad excesiva: Imaginemos que queremos mostrarle al comercial la disponibilidad de un determinado modelo de vehiculo, es decir, si está en stock. El objetivo de negocio es que sepa si puede vender ese modelo o no. ¿Para qué vamos a contar cuántos vehículos hay disponibles de ese modelo? Le da igual si hay 24, solo necesita saber si tiene una unidad disponible para la venta o no la tiene. Para darnos cuenta de este exceso de complejidad tenemos que recordar el objetivo de la release. Recordar el propósito de la release actual.

Cuanto menos software escribamos mejor. La linea que no falla es la que no está escrita. Cada linea que escribimos es un compromiso que hay que mantener, hasta que alguien venga y la borre. Cuanto vamos justos para cumplir con el objetivo de la release (en el mundo del software esto es siempre), debemos recortar en alcance (funcionalidad) y nunca en calidad. Hay que hacer todo lo posible por respetar los tiempos de entrega previstos, consiguiendo el objetivo a base de quitar características menos importantes en el momento actual.

2014: Un gran año

Últimas horas del 31 de Diciembre de 2014. Para millones de personas es un día de celebración. Aproximádamente el 75% de la población cambia de año cada primero de enero siguiendo el calendario gregoriano, aunque solo unos pocos podemos hacer una fiesta. Para muchos es el último día de su vida, para otros es el primero. Según la ONU, más de 30 millones se encuentran desplazados a causa de conflictos armados y muchos de ellos están en plena guerra, luchando por la supervivencia. Muchos morirán de hambre y otros por enfermedad. Miles de millones de animales sufren el holocausto en las granjas y mataderos industriales para satisfacer a una minoría de los humanos del planeta. Y el planeta según diversas organizaciones está en el peor momento de la historia.

Sin ignorar todo lo que está ocurriendo aún hay margen para el optimismo, la esperanza y la gratitud.  Mi deseo es ser cada día más optimista y más féliz sin necesidad de amnesia, ignorancia ni indiferencia. Haciendo por los demás todo lo que esté en mi mano. Consumiendo de manera responsable.

La hoja de ruta consiste en vivir el momento presente con atención, agradecido por tantas cosas buenas que me suceden.

2014 ha sido el mejor año de mi carrera profesional desde que trabajo como independiente. Todo lo que podía salir bien ha salido bien. He tenido la suerte de visitar multitud de empresas y trabajar con gente genial. He tenido tanto trabajo este año que no voy a citar todos los lugares por los que he pasado y personas con las que he trabajado porque se me quedaría gente fuera seguro.  Me ha encantado ver trabajar a algunos colegas del gremio como Luis Fraile o Luis Ruiz Pavón y ha sido un placer descubrir a Carlos Bastos.

A principios de 2013 pensaba que debía centrar mis esfuerzos en el mercado extranjero, sobre todo UK y Alemania pero este año el mercado nacional me ha dado mucho más de lo que esperaba y he salido poco fuera del país. Prácticamente cada semana recibía alguna petición para formación o consultoría y he tenido varios encargos de desarrollo de producto a medida con los que me lo he pasado bomba. He conseguido programar tanto como quería. También he podido empezar a grabar los screencasts de programación que quería (y haré más).

Pero lo más importante son las alianzas que se han ido fraguando por el camino. Sin buscarlo estamos cerrando el año funcionando como equipos en lugar de ser un profesional solitario. Estoy encantado de cerrar el 2014 trabajando con mis compañeros Luis Rovirosa, Juan M. Gómez, Imobach Martín, Nestor Bethencourt, Modesto San Juan, Alfredo Casado y Fran Reyes. Y con todos los compañeros de AIDA (ahora cuento más). 

Luis Rovirosa está ayudandome con consultoría y formación en varios clientes, es un aliado con el que llevaba tiempo queriendo colaborar. Juan, Imo y Nestor estan desarrollando conmigo el editor de plantillas del popular MDirector, la herramienta de email marketing de Antevenio, un proyecto muy bonito. Alfredo, Modesto y Fran están conmigo y con el resto de compañeros de AIDA trabajando en un proyecto apasionante para el Grupo Domingo Alonso. Y hay más proyectos en camino. Por ello estoy en proceso de constitución de un SL, la que será mi segunda SL. Estoy ya cambiando la portada de esta web (carlosble.com) y pronto habrá mas fotos e info de todos.

Con semejante grupo de profesionales podemos atender toda la demanda que me llega y puedo estar tranquilo al delegar. Poder delegar sin preocupaciones, no tiene precio.

Cerrar el año trabajando para Grupo Domingo Alonso es una suerte. Se trata de una de las mayores empresas de Canarias aunque yo no la conocía porque los coches no me llaman la atención. Surgió una consultoría con ellos, en parte a través de nuestro amigo y maestro Jose Juan Hernandez de la ULPG y pude conocerles. Me quedé encantado con la calidad humana del equipo, sus valores, su energía y con el proyecto en sí. No tenía intención de proponerles colaboración para sacar adelante el proyecto pero cuando volví a casa y pasaron unos días me dí cuenta que yo quería trabajar allí y les mandé una propuesta. Es un super reto, la construcción de un complejísimo Dealer Management System. El reto es tan grande que necesitaba pedir refuerzos y para mi sorpresa, tanto Alfredo como Modesto y Fran lo dejaron todo (bueno, a sus parejas no!) y se mudaron conmigo a Gran Canaria para meterse en el proyecto. Llevamos dos meses de proyecto y cada vez me gusta más todo lo que conozco. El capital humano de AIDA (Aplicaciones Informáticas Domingo Alonso) es increible. En la fiesta de navidad nuestro compañero Alejandro Artiles se curró este gracioso vídeo explicando lo que estamos viviendo en estos comienzos del proyecto, al estilo "Stars Wars":

Por si fuera poco, en Junio de este año mi padre volvió a nacer. Ingresó en urgencias y los medicos dijeron que no sobreviviría. Un fulminante cáncer de cólon. Sin embargo lo ha superado por completo en muy poco tiempo. Mi padre cuenta la experiencia en su blog. Ha sido la mejor noticia del año, lo mejor que ha sucedido.

Este post es sobre todo para daros mil gracias a todos los que estais haciendo posible este grandísimo momento. Gracias a todos los que este año habeis contado conmigo. Ha sido un placer y estoy seguro de que viene mucho más por delante.

Gracias a Dácil por estar siempre ahí, por ser mi motor. Gracias a mi madre por cuidar de todos nuestros animales del refugio cuando yo no puedo hacerlo por mi trabajo. Este año, sin mi madre no hubiera sido lo mismo, no sé cómo lo hubieramos hecho.

Caramba! ya es 2015! Próspero año nuevo!

Practising Mob Programming

mobProg1

In the past edition of Socrates UK, I met Gianfranco Alongi who told us about his team's experience with  Mob Programming. It was the first time I heard about it. As the site says, Mob programming is people working at the same time, in the same space, at the same computer, on the same thing. Gianfranco said it was very useful for them.

At the beginning of November three of my fellow craftsmen and I joined a team of other 12 developers to work on a new project. We are building a DMS (Dealer management system) and an IMS (Importer management system). The project is very exciting but we don't have a clue on the domain. We are also a lot of people with different programming styles. So we decided to give Mob Programming a try and after a few weeks the results are very positive.

 

Some lessons we have learned along the way:

  • Like with pair programming, navigators should take notes whilst the driver is at the keyboard, rather than disturbing him constantly.
  • Only when the driver raises his hands off the keyboard we are allowed to discuss.
  • Rotate frequently: it's faster to jump in the keyboard and do it yourself than trying to explain the code you envision.
  • Limit the group size to 5 or 6 people. We find that 4 is a good number, more than that is not being productive for us. Sometimes it's useful though, when we want to define conventions for the whole team.
  • The group should be stable: if new people join the discussion in the middle then we have to explain again and again the code and the decisions we have already made. It's like the never ending story.
  • At some point I had to leave a session right in the middle of something. When I came back a colleague told me that the people who were shy or less proactive during my driving period, started proposing interesting ideas during my absence. The people considered "seasoned" or "experienced" should go away from time to time for the others to feel empowered.

So far the project is just fantastic. People are awesome, learning incredibly fast, very enthusiastic. Everyone wants to learn and contribute. We are all learning a lot and doing our best. I can't think of a better project. We are very lucky.

mobProg2mobProg3

 

 

Programmer’s memory

By pairing with a wide variety of other programmers, I've noticed that the programmer's memory has an important impact on the productivity. In order to be agile searching for code blocks within a file, we must remember the structure of the code, be familiar with the code geography. We should have a mental map of the file that we can handle in our heads, so as to remember whether certain block is located near the top, near the middle or at the bottom of the file. When the file is too big or the developer doesn't make an effort to build the mental map, he starts using the IDE's search feature to navigate everywhere, even when the code block is present in the current screen. Searching for code blocks with the IDE all the time, stops the flow and thus reduces productivity. The focus goes away. Well, this is what I've seen and I've experimented whilst pairing.

Different people have different memory capacity, the trick is to be aware of your capacity and manage it accordingly. If you can't handle files longer than 300 lines of code, then keep your files below that size. When you find yourself using Ctrl+F to search for a function name often, consider splitting the file into several ones.  The same applies for packages, modules, namespaces... try to group artifacts so that you can handle a mental model that contains all you need to work on the task or feature at hand.

Coding requires a lot of concentration and all the attention that we can put on ourselves to improve our own process day after day. Every coding session is an opportunity to learn and improve. Specially when you pair and get immediate feedback from your pair.

I believe this has a relationship with developer's preferred font size. The bigger the monitors are, the smaller I see people's fonts. I need a magnifier to be able to read to code sometimes, I always have to ask them to enlarge the font. Smaller fonts means more lines in every screen but anyway, most people work with horrible mountains of legacy code and it doesn't fit in even 5 screens!

Use your memory and save your eyes!

I had a blast at SocratesUK 2014

Last week I participated in SocratesUK for the second time. I learned many things, met amazing people and had a lot of fun.

I flu from Tenerife to London the day before and met Sebastian Larsson in the pub where we had a nice chat on professional careers, talking about the resources and techniques we use for improving our skills.

---------- On the way to Cotswolds -----------

The next day I went to meet Sandro,  Gonçalo, Samir and Emanuele - part of the Socrates' team. Sandro drove us to the venue. It was a nice journey, full of rock and fun.

I had the luck of sharing room the Nicole Rauch this time although we almost didn't see each other, there were many things going on so as not to stay in the room for long.

After dinner Codurance sponsored a selection of craft beer in the main room. In that room there were several flipcharts and that helped to host very interesting discussions. Steve Tooke explained the benefits of Specification by Example when we started talking about Cucumber.

Discussing with beers

--------------- Discussing with beers ---------------

 

This year I came up with the idea of booking a dedicated room for deliberate practice where one could code and pair all day long. I exposed the idea during the proposals in the next morning and got the room. The idea was to work on code katas or pet projects together. During the day there were always people in the room but the truth is that for many people it wasn't clear what to expect from the "workshop room".  I had fun pairing with Stefano Cadario and Matt Glover among others and facilitating some exercises like the Word Wrap kata. Next time rather than booking a room I'll be at the bar with my laptop ready to code. I was unlucky this time and my laptop's screen got broken during the flight.

There were like six or seven tracks going on at the same time, some in the garden or the bar and  fortunately none of them was about Scrum or Kanban!

After dinner Pawel Duda and I started a pair programming session at the bar and we ended up doing a kind of Mob Programming with Matt, Uku, Sebastian and Jan using tmate - a terminal sharing tool. We worked on an experiment, trying to solve a Sudoku from the outside in, stubbing out smaller functions. It was kind of brain fuck, it was good practice and fun. Working on experiments, trying different techniques to those you usually apply is one way to improve your skills.  The problem was quite hard and there were situations where Pawel and I couldn't see a mistake and then Matt or Uku spotted it on. I believe somebody took pictures of us, please let me know if you find them out.

sessions in the garden

-------------- Sessions in the garden -------------

 

 The next day I ran a two hours workshop on the fundamentals of TDD and Pair Programming, an introduction. We were just a handful of people which made me realise that most Socrates' participants were seasoned practitionersNaseer Ashraf and Sebastian came along to help with their vision after years of practice. It was really good as we had complementary opinions to make the discussion enriching. It was very nice to see how Matt and Nic Infante realised the value of PP and TDD in terms of empathy and productivity, they found a sustainable pace.

Samir's session

-------------------------- Samir's session ----------------------

Ivan Moore showed us the "refactoring golf" exercise before lunch. I find it useful if we get rid of the "points" and focus just on keeping the tests green.

In the afternoon I attended to Samir's session on refactoring. The exercise was very interesting - avoid primitives in the code and then add new features. The repository is here.

Later on that Pawel and I went to the tiny gym beside the reception desk to work out together. Pawel is an amazing guy. Being able to do some exercise raised my energy levels.

Mob programming

Mob programming on Saturday night - Look how much we cared about the football

After dinner a bunch of us went back to Samir's code, this time in front of the projector, running a Mob programming session. A different person was at the keyboard every 7 minutes with Pawel controlling the time rigorously. Interestingly enough the person at the keyboard always tried to understand and learn IntelliJ shortcuts and the Mac keyboard. Everyone was trying to learn and bring value in a very respectful atmosphere. I was sincerely amazed but the suggestions of my fellow craftsmen.

On Sunday morning I was late to join the group on their walk through the beautiful country side so I stayed in the hotel. In the bar again people were pairing. I started a kata with Sebastian in Java. Then he had to set off but Steve and I took over using Erlang. It was my first Erlang program and I believe Steve's too. I learned several tricks on Vim thanks to Steve and some Erlang which is very cool. This is the code. Unfortunately we didn't commit often to show all the intermediate baby steps.

The way back to London was also very nice. Mashooq took Oliver and Raph to the airport and then gave a lift to Pedro and me. We pretty much crossed London by car it was my tourist tour thanks to the infinite patience of Mashooq. It's funny that I should have met Pedro in England after he's been living in Barcelona for so many years. His Spanish is better than mine! I am glad he is part of Codurance.

I like this year's edition more than the one before but I think it had to do with my attitude and the fact that this time I knew more people already and I had different expectations. Half the participants were new anyway.

What I like the most about this conference is that I get to meet people from whom I can learn a lot but at the same time there is no hierarchy we all treat others with respect. It's definitely important to run open spaces on software craftsmanship where it's about developers, practice and learning.

For this reason some friends and I are thinking of organising and hosting Socrates Canaries on the next winter, when it's cold in Europe but warm in the Canary Islands. I'd like to hear from you, would you participate in Socrates Canaries? Please fill in the form and give us your opinion.

Thank you so much to the organisers and to Rachel Davies our excellent facilitator. Thanks also to Farncombe's staff that kindly provided me with a vegan option on every meal - it was delicious. If I can make it next year, I'll be there again!

I am starting to work on a new project for a new customer, I'll join the team for a couple of days or perhaps weeks. They have been spiking and eventually have decided they want to develop the front-end using Marionette.js a library on top of Backbone.js together with Require.js. I've done a spike to show them how I'd structure the files, the app and the different kinds of tests.

The app is dead simple. The is a form with two fields, "description" and "url". When the user clicks on the button below, a new link is added underneath. So it's to add links to a panel.

Versions used in this working spike:

  • Jasmine.js - v2.0
  • Require.js - v2.1.14
  • Marionette.js - v2.0.1

The repo is here:  https://bitbucket.org/carlosble/marionette-testing-sample/overview

Structure:

  • bower_components - dependencies
  • node_modules - dependencies
  • index.html - launches the app
  • uiTests.html - launches Jasmine tests against the DOM, using Require.js
  • actionsTests.html - launches Jasmine tests to test business logic
  • js - this is the production code
    - app.js
    - views.js
    - models.js
    - actions.js
  • spec - these are the tests
    - viewsSpec.js - interact with the DOM
    - actionsSpec.js - no interaction with the DOM,  works on the business logic

With this structure the business logic don't have to depend on Marionette,  although it depend on Backbone models and collections.

Resources that help:

 

No, it’s not the money

I totally disagree with the idea that ultimately we write software for money, for someone to make money -- or more money. I can't bear with sad statements like "well, eventually we get paid to produce revenue" or "at the end of the day what counts is the money", "we do agile to make more money" or just "show me the money!". Bullshit.

If money is the only purpose, agile methods are not going to help you!

During my years as independent developer and consultant, I've observed two primary reasons for agile methods to fail. One resides in the top management (not every manager!) whilst the other is in the technical side - the developers (not every developer!).

Top management's problem

When top managers care more about money than they do about people, sooner or later employees  feel that they are just numbers, resources and agile methods can't help. There is no point in trying to talk about Scrum or XP to those top guys, because what they really have is a crisis of values. A big problem of perception. What they really need is executive coaching, not agile practices. I don't think we should encourage them to attend agile conferences, we should rather recommend them a really good life coach, psychotherapy, meditation, yoga, sport...

Important: I am not talking about all the managers, just about some people.

Money should never be a goal in itself. We write software to solve people's problems, because we care about others and want to improve their circumstances. Or perhaps just because we enjoy doing so. Money should be just one consequence of doing our job right. The disease  that is killing our planet is cancer. When the goal of a company is just to make more money every year,  to increment the "growth", that's a cancer. Unlimited growth is cancer. It kills the human body and at a large scale it's killing the planet. Agile values and principles do not scale up in economic terms, like many other things - Jorge Uriarte talks about it in his brilliant talk in Spanish. 
Money does not buy happiness because money can't buy an eternal life and health. Rich people are never satisfied because money is not fulfilling so they become gollums - let me refer to another brilliant talk in Spanish this time by Joan Antoni Mele.

If you happen to be an employee in one of these companies don't be confused, the problem is deeper at the basis of the system, it's not your fault. There are actual reasons for you to feel the lack of purpose and hence motivation. You can try to change things within your team or area, do your best for them, learn and share in that circle but it will stop in there. It could be a good time to reflect on where and how you want to spend your energy, your life.

Developers' problem

On the other hand the reason why agile methods fail sometimes has to do with some developers. We ruin the code, remember?We must learn to say NO, to have the courage to face the truth even when it's not nice and talk about it. Of course we must deliver excellent quality software and accomplish our commitments. The XP practices are intended to promote the principles and values that help developers behave like professionals. I travel often to mentor developers in many cities and what I always find is a dramatic lack of knowledge, technical skills.  Really smart people but missing basic knowledge. Because the majority of us haven't been taught by professionals. Fortunately we can work around that, I think conferences and other events are great tools along these lines -- apart from training and mentoring. Deliberate practice is very important and communities help a lot with this. We practice together to improve our skills. The more I read about Software Craftsmanship, the more I feel on the same page. I highly recommend the book by Sandro Mancuso on the subject, I am not gonna try to repeat his inspiring words. This is why I believe less in "agile events" and "agile communities" and more in communities of practice.

If it's not money, then what is it?

You have to find it by yourself. I can tell you that I don't work for money, it just comes in as a matter of doing what I like, the best I can do it. It's not always easy, sometimes it's actually scary but it works. I like to think I wasn't born to be a money machine. The desire of being helpful to others is my driving force. I know I won't be effective if I can't get that feeling.

Daniel Pink says that our motivation comes from autonomy, mastery and purpose. These are good goals in themselves rather than means to produce money. Nice example, isn't it?

To close this post, I leave you with this powerful keynote by Martin Fowler about the role of the programmer:


 

A week to remember in Barcelona

Last week was awesome, I went to Barcelona to run two training courses. Well, one of them was my yearly session at the Postgraduate on Agile Methods at La Salle (Universitat Ramon Llull). The first postgraduate in the world on Agile Methods. I explain eXtreme Programming, together with my good friend Rubern Bernardez,  during 6 days (3 weekends).

PMA 2013/2014

PMA 2013/2014

 

This has been my third year at the PMA and it's been really nice. The selection process for participants went very well thanks to Xavier Albaladejo and so the group was excellent. People have made an endeavor to understand the XP practices and the values behind. Even project managers, people that have been away from code for years, were test-driving the exercises in pairs.  The fact that decision makers come to the class and get to appreciate the benefits of clean code and XP is very important in my opinion.  Because they can encourage and tell developers later. In the group there were testers and developers too. The different mindsets together were very interesting when facing code. Enriching experience for everybody. Thank you all for this great PMA edition. Special thanks to Xavi and to Quim Ibañez for his kindness and support.

 

During the week, I gave one of my TDD training courses, this time open to the public. In general, public courses are more energizing than in-house, because people are willing to learn and participate. They have to pay for their ticket or ask their companies and that makes a difference. This time I got to know several members from the Barcelona Software Craftsmanship Community. The level in the training was very high, in fact, it was more an exchange than a teaching session. There were many interesting discussions and retrospectives whilst looking at the code in the projector.  It's been also very nice to meet old friends and observe how they have progressed over the last couple of years. Specially Manuel Rivero who has made an outstanding progress in his career and now let me learn from him.

 

TDD Training in Barcelona

TDD Training in Barcelona (open to the public)

This experience reminds me my first open course in Madrid in 2010, when I got to know people that are now good friends and that today, run their own training courses on TDD and clean code or lead teams. So I believe that we have started here a wonderful relationship and that we will cross roads soon again. There was magic in the air.

I have to say thank you to my good friend Javier Gomez for all the support and the hosting,  as the event happened in Ricoh Spain. In this kind of courses I get to know great programmers that usually end up being colleagues or collaborators at some point ;-)

Coding dojo - Barcelona Software Craftsmanship

Coding dojo - Barcelona Software Craftsmanship

 

Thank you very much also to all the folks that came to the coding dojo that we had on Monday evening, hosted by Barcelona Software Craftsmanship, thanks to Manuel Rivero, Beatriz Martin and Jaume Jornet. In my opinion the community is very healthy in Barcelona, congratulations.

With good names for packages, classes, methods, variables,... code should be self-explanatory.  Long method names are not a problem if they really make code read better and don't reveal too much implementation details. Names are more powerful than most developers usually think, they have a profound impact on our designs. In general names should be pronounceable but there are always exceptions.

  • In a small loop, it's OK to name the index i, j, k or something like that you don't have to say theLoopIndexWhatever. In fact, "i" reads better in a short loop.
  • Methods should not contain concrete details, those should be parameters instead:     

            assertThatThereAreTwoResults(results)

          Should better be written like:

                      assertThatThereAre(2, results)

  • Method names should say what they do, but not how:

            addWordIfIsValidAndHasCorrectLength(word,  results)

          Should may be:

                     addValid(word, toResults);

  • The name of the class should be considered when naming methods. The name of the methods should be considered when naming its arguments. Given that methods should not have more than 3 parameters (the less the better), the names of the arguments may be combined with the name of the method, specially if there is a single parameter. Good names care about their context.

            result = expressionResolver.resolveExpression(expression)

          Reads better like this:

                     result = resolver.process(expression)

  • In the case of test methods, the name should describe the behavior without concrete details. The details are inside method body. The test method name is the description and the body is the example:

            one_plus_two_returns_three()
          Should be:

                     sums_two_single_digit_numbers()

  • Names should not contain technical details, like the types , because they are an excuse not to search for proper domain names. Modern IDEs provide enough help for the programmer to find out types, code should be business domain oriented.

            parseString(expression)
          Should be:

                     parse(expression)

Avoid prefixes and suffixes like "Abstract*", "I*" (ISomething), "*Impl"...

Don't let the syntactic noise bother you when choosing your names, the fact that there is a brace in the middle should not impede you from writing a line of code that reads like well-written prose ;-)

I'll probably will go on updating this post with more examples.

 

iSQI logo

I am happy to announce that the work  I've been doing in the last quarter in collaboration with iSQI is now official. We have prepared a new TDD training based on the successful course that I've been running in Spain for about 3 years. The new training is now part of iSQI's Certified Agile program, so those who want to take the exam after the course will become certified (if they pass it).

iSQI is a well-known organization in Europe specially among testers. Their CAT (Certified Agile Tester) is quite popular and I can tell is a good training because I participated in one edition just to see how they work. Now iSQI also wants to provide more training options for developers.

I've created a hand book for the participants and a guide for trainers, updating my original course with an additional day and new exercises.  In January I'll be in Berlin running the first Train the Trainers (TTT) where developers passing the exam will become trainers entitled to run official courses and certify other developers.

I do know this training provides great value to developers. I encourage people new to TDD to participate in the training because I know they will learn. I would discourage those who want just the certification because this one is not easy to get.  The exam is mostly coding to demonstrate that candidates really understand TDD. Last month we had the first pilot training in Potsdam (Berlin) and only half the participants passed the exam.  Fortunately all of them learned something new and I can tell that if they keep practicing, they will pass the exam in a few months. But at the same time I am satisfied that not everybody passed the exam because we had some people that haven't been coding in the recent years and I felt they were not ready yet.

I don't know about other certifications because I don't have any, and the value of this training is not in the certification either but in the important lessons participants learn. However I can confirm that the people passing this exam will know what TDD is, and what it's not and that provides value too. We are doing a good job there.

My challenge now is to train other trainers so that we preserve the essence of the course adding even more value and quality.  If you are a seasoned test-driven developer please join us as a trainer :-)

We know TDD is not mainstream and will probably never be, but I see in this a great opportunity for TDD to reach more developers. An opportunity for developers to feel comfortable asking their managers for three days to come and practice and then keep on practicing on a regular basis.

Even though the title of the training is TDD, we cover some basics on clean code and SOLID design principles to make sure we triangulate towards well-designed code. The emphasis is on good naming and removing duplication. The first day is all about refactoring, unit tests, and design principles.

For my friends in Spain I have to say that we would like to translate the materials to Spanish and run a TTT somewhere in Spain and also in Latinamerica. Probably in Mexico and Colombia. But we don't know when is this going to happen or whether it will happen eventually. For now, all is in English and the first editions will happen in Berlin. But if I can give the course with my bad English, you can for sure participate ;-)

All the information and contents about this training is here.