Carlos Ble

Carlos Ble

I am a professional software developer, I solve problems.

I also teach and mentor developers to build better software.

Developing software since 2001.

Can I help you?

  • Do you need high quality tailor-made software?
  • Need training on TDD, clean code or refactoring?
  • Do you need a technical consultant?
  • May I pair with you to write better code?

Events

Upcoming training courses:

  1. TDD - [en Español] - 6 y 7 Octubre
    Gran Canaria
  2. TDD - [in English] - October 20, 21 & 22
    London, UK
  3. TDD - [en Español] - 29, 30 y 31 de Octubre.
    Madrid, Spain

Conferences:

  1. I'll be at the Agile Testing Days 2014
  2. I'll be at the London Test Gathering Workshops.

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:

 

Learn TDD on the beach

I am glad to announce that iSQI and I are organizing a TDD training course in Tenerife, open to the public. Rather than running the course in Potsdam (Berlin) we have decided to move it to the island this time.  In the south of the island, by the beach.  There will be participants coming from the Netherlands, Austria and other European countries. And you dear reader are still on time to join us. In this edition there might be different profiles, people new to TDD and experienced test-driven developers that want to become trainers. Some people will learn TDD from scratch and some other people will learn how to teach it.  At the end of the course there will be a certification exam.
It's the first time we organise it in Tenerife and I am looking forward to it.  Apart from the learning experience,  it's a perfect occasion to visit the island, bring the family and enjoy the sun and the sea.  I may even organise a walk through the shore or the mountains.I hope this will be the first of several courses in this beautiful island where the weather is perfect during the whole year.

The week afterwards, I'll run another TDD course but this time in Spanish and in Gran Canaria, the neighbour island. The registration form will be published soon.  Thanks to SPEGC, the price will be cheaper as they are funding part of the training. In this training there will not be a certification exam.

Two TDD courses, open to the public  in Canary Islands this summer - this is good news! :-D

 

 

In a previous post I wrote some examples of method names that use their arguments' names to form an expressive expression:

  • Users findBy(String name){...}

It reads well when looking at the method definition but it may not read well when used:

  • users = findBy(someReallyBadVariableName);
  • users = findBy("bob");

In this case I can prevent consumers from writing unexpressive code with some redundancy:

  • Users findByName(String name){...}

But the redundancy may be annoying in some cases, so when may I avoid the redundancy?

I believe it depends on:

  • If the method has more than one argument, I can't count on the argument's names - still they have to be good names.
  • The level of abstraction of the method:
    If the method or function is a low level one, like in a general purpose library, then I prefer to have some redundancy because it's hard to tell how is it going to be invoked. On the other hand if it's closer to the domain then the usage gets narrower and I feel better counting on the argument's name.
  • The type of the argument - are they primitives or objects?
    If the argument is a primitive like a string, someone may pass a literal into the function thus making the readability bad. However if it's a domain object, literals are not possible and variable names use to be more precise:
    generateOrderFor(shoppingCart);

What others heuristics do you usually consider?

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:


 

I've been watching and studying K. Beck's video series on TDD this week. These screencasts are really good in my opinion, I am glad that Kent made them. I would like to see more of them.

According to Amazon, I bought Kent's book on TDD in January 2008. At that time I was working on a kind of experimental project at the University of La Laguna so I had plenty of time to practice TDD all day long. The software had to work but there was no deadline, it was a kind of grant, perfect for me to learn and practice. And we delivered clean code that worked finally. Well, today for sure I wouldn't like that code.

With Kent's book and the help of the TDD mailing list (Yahoo), I embraced the technique soon and stuck with it since then. So my style is quite "classic", although I believe I use more test doubles than Kent (looks like he doesn't use doubles at all, but I'd like to see that). However as I've gained experience and learned from others and from my own mistakes, my style has been evolving over time. Moreover teaching TDD to lots of  people during these years has have a huge positive impact on the way I test-drive my code.

But now watching Kent coding has been a bit surprising to me. Notes to myself about the episodes:

Episode 1:

Kent writes the first test from the outside-in, but makes it pass bottom-up. Using a single test as a means to constantly validate the code he is writing works. He moves code from the test to production and back to the test, always moving in safe steps. My surprise he is that all the triangulation is performed with a single test, an evolving end-to-end test. I think I'd probably have written several tests, leaving the first one red for a while (he does that in an upcoming episode). From this very first episode I can notice that Kent uses the tests to maximize feedback, focusing on getting things done. Very pragmatic, I like that.

Episode 2:

Kent uses the "fake it until you make it" trick, returning a hardcoded zero value, but then rather than writing another test to triangulate, he uses the same one to make the production code more generic. Again very pragmatic. I only use "fake it until you make it" when I don't have a clear vision of how to make it pass. That keeps my flow and gives me some inspiration. So in this case I would just write something more than "return 0".
The surprise in this episode is that Kent prefers to leave some duplication in the code in favor of symmetry. Duplication makes me feel unconfortable so I would rather remove it. Now I value symmetry a bit more, I got his point.

Episode 3:

Kent removes several tests. In order to split a problem into smaller pieces, he leaves a failing test and moves on to test-drive those small pieces (methods) that are needed. When the big method works and the big test passes, he realizes the small methods should be private and so changes their visibility. Then the small tests don't even compile and Kent just deletes them. He calls these "scafolding tests", needed to flow with safe small steps but not necessary in the end.
To me this is a bit surprising, it's definitely not my style but I see the benefit - flow and fast feedback again. I rarely delete tests, only when they are proven redundant (and I loose the 10$ as Kent says). When I find myself testing a method that should be private I question my design. It usually tells me that the method probably belongs in a different object where it's public. If writing a specification (what tests really are from my point of view) turns out to be difficult, that gives me a hint about my design. However it's true that sometimes premature design decisions may get you stuck, loose the flow.

Episode 4:

I really like the idea of test-driving the same problem from scratch several times to find out which order is the best. Choosing the tests appropriately is very important for TDD to be productive. To success with triangulation the order in which we choose tests is fundamental. This exercise is excellent, I will practice it more often with code katas.

Some conclusions:

I can see that Kent uses the tests to progress with steady pace in safe small steps, maximizing fast feedback loops. I see that the primary focus of his tests is not on documenting the behavior of the  system, Kent just wants to get code working soon. The names of the tests are readable and tell a story but I like them to be more expressive. Sometimes Kent reflects only the input in the name, whilst I prefer to describe the behavior. As an example I would type  "it_is_not_possible_to_remove_a_null" whilst he typed "removeNull". I continously refactor my tests to improve their names, making sure I could copy and paste those names (together with the class name), paste them into a text document and deliver it as human readable documentation source.

I tend to use tests more as specifications than tests so I probably spend more time thinking of the tests and ordering them for the sake of an effective flow aftewards. The truth is that sometimes it's hard to approach the problem from the outside-in and the pragmatism demonstrated by Kent helps with that. I'll take advantage of these lessons to keep on evolving my style

 

Thank you Kent Beck for your book and your videos!

And thanks to my friend @pasku1 because I believe he told me about these videos. 

Code symmetry

Today, Peter Kofler and I have been pairing over the Internet to do deliberate practice. To improve our coding skills. We have been working on the word wrap kata, to practise the Transformation Priority Premise, this time using JavaScript. We've checked-in the code after every little change so the evolution can be seen in the "commits" in the repo.

What I have learned in this session:

  • I will always use curly braces in "if" statements even when they only contain a "return" statement: I used to think that, even without the braces,  developers would notice the "return" and thus avoid the mistake of adding lines afterwards. But Peter suggested that some developers might add lines before the "return" statement. This is something I didn't think of before!
  • Code symmetry helps to explain the intention of the code.

Code symmetry started to grab my attention when I saw Kent Beck in his TDD screencasts. In the second episode he prefers to leave some duplication in favor of symmetry.

Peter and I were working on a simple function to find out the position where we had to wrap the line. We had a green test with this implementation:

  1. function wrapPosition(paragraph, maxLineLen){
  2. if (paragraph.indexOf(" ") > -1){
  3. return paragraph.indexOf(" ");
  4. } else {
  5. return maxLineLen;
  6. }
  7. }

Then I noticed that the "else" was not necessary so I removed it:

  1. function wrapPosition(paragraph, maxLineLen){
  2. if (paragraph.indexOf(" ") > -1){
  3. return paragraph.indexOf(" ");
  4. }
  5. return maxLineLen;
  6. }

The Peter said, "now the 'if' statement looks like a guard clause, but in reality we don't have such a guard clause".
This is true, the reader may wonder why is that guard clause in there. Actually we know that any of
the two paths is possible, so the "else" expresses the intent of the code better.

But we still thought that the "else" was not necessary, so Peter came up with the idea of inverting the condition:

  1. var lineBreak = "\n";
  2. var notFound = -1;
  3. function wrapPosition(paragraph, maxLineLen){
  4. var hasNoBlank = paragraph.indexOf(" ") == notFound;
  5. if (hasNoBlank){
  6. return maxLineLen;
  7. }
  8. return paragraph.indexOf(" ");
  9. }

Now it does not look that much like a guard clause. What do you think?

Some related talks and posts that Peter has sent to me, related to our discussion today:

It's been a very interesting discussion, I want to say thank you to Peter for arranging this session. There will be more soon :-)

 

 

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.

Teaching TDD

TDD class at the IronHack 2nd edition (picture by @JackLondon84)

Last week I was the teacher in the second edition of the IronHack, well for the last two days of the week. This time I've joined the group on their second week rather than the fifth. So I've been the one introducing unit tests. It's been quite challenging as it had to be using JavaScript. Many new concepts at the same time. Really hard for the participants but eventually absolutely all of them understood the benefits of unit tests and even the TDD cycle. They got the point with TDD. Fortunately,  my friend Fernando Moreno (who was a participant in the previous edition), was helping me out with the class. He was solving doubts and helping with technical problems and that made a huge difference. Being two people answering questions, was the key for the group to progress with steady pace. I am so grateful to Fernando, a great teacher assistant.

The group has a great potential, this training course is going to be a remarkable milestone in the life of many participants. It's been a pleasure meeting the folks.

And... you know what? pretty much all the participants from the first edition have a job already. And I know that some of them are really interesting positions. This is great news, I had the chance to talk with four of them and they are very enthusiastic about their new careers. This fact says a lot about the IronHack project and I am glad for being part of it. The more I know the project and the people behind it, the more I like it.

On Thursday evening Marta Fonda (from edition one) came up to give a talk on personal branding after my class, it was a nice surprise and we had a great time with beers afterwards.

On Friday I organized a small coding dojo in the same venue and I had the chance to pair with Sergio Revilla and Vishal  Shahdadpuri, from the first and second editions. We had a great time, I could appreciate Sergio's evolution which is impressive and we learned from each other. Pasku came out with a nice solution in Ruby. We ended up with a nice solution in JavaScript, also using a functional style.

I will back in the IronHack this summer in Barcelona. Check out their new courses on iOS development, in Madrid & Barcelona (summer and autumn).

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.