Books I’ve read this quarter Q1 on 2015, as inspired by Manuel, on this post:

• Fifty Quick Ideas to Improve your User Stories, by Gojko Adzic and David Evans
• Fun retrospectives by Taina Caetano and Paulo Caroli
• Implementation patterns by Kent Beck
• Clean code by Robert C. Martin; again

Books started, not yet finished (WIP):

• The Well-Grounded Java Developer, by Benjamin J. Evans and Martijn Verburg
• Refactoring, by Martin Fowler, (with Kent Beck, John Brant, William Opdyke, and Don Roberts)
• Growing Object-Oriented Software Guided by Tests, by Steve Freeman and Nat Pryce
• Flow, by Mihaly Csikszentmihalyi

(Note: I’ve written this list a posteriori, in May 2015)

This is the first post is of the growing-software series

A few weeks ago, while reading the book Growing Object-Oriented Software Guided by Tests by Nat Pryce and Steve Freeman, I finally understood why the software needs to be grown and not built:

A few days ago, I was thinking about new inspiration sources and this came to my mind:

In agriculture, at least in this latitude, there are different seasons. Different plants have different temporal schedules: you need to plant, wait for it to bloom, produce fruits then collect. Maybe remove the plant and wait for the next time slot to appear.

When growing software, things are different (or we think so):

• Do we need to plant? Yes, seed the project with resources
• Wait for it to bloom? Yes, from an outside actor perspective, there is no result for a while, even if it is one sprint
• Wait to produce fruits? Yes, usually some sprints past the minimum viable product (MVP) until the minimum lovable product (MLP)
• Do we need to collect it? Yes, usually the final tests (e.g., regression) and ship it to production to be used.

After all, we might say that the process is not so different in both activities. Nothing to do related to tools or materials, etc.

As in agriculture, seasons vary in productivity for a certain activity or crop: during the cold months, not many plants are able to produce fruits. Meanwhile, during the hot months, harvest is much higher. (This only applies to outdoors gardening.)

When producing software, there might be seasons too:

• Seasons where productivity (harvest) varies
  • Lowers when a new team member joins (see the Mythical Man-Month), the pressure is too high, salaries are low, …
  • Increases when there are no information silos, the bus factor is high, the team is not affected by external distractions, …
• Seasons where different harvests can be planted, but a subset of them will be the most effective
  • A front-end developer can do back-end, but it won’t be as productive. In this area, one can learn other disciplines and get as effective as other professionals.
  • There are many tasks to be done but the prioritized ones are more effective
• Some harvests are more intense on the fields than others. After that, there is a required rest so the next season is as productive as the previous one
  • Some projects produce burn-out so some slack time is more productive than getting to work again.

But there might be differences too:

• Geographical distribution: some crops cannot grow in certain conditions. I believe any geographic area (e.g., country) can produce any type of work (e.g., back-end, front-end, quality assurance, project management, etc)
• Quality distribution: same as before, many crops do not grow in Iceland (due to the harsh environment) or do it with lower quality as nearer to the Equator.

Xavi Gost responded to my tweet:

[Roughly translated: Concepts like allowing some time for things to grow and ripe would benefit the industry]

Get the tools out of the tool-shed and start buying seeds for this spring.

Adrian Bolboaca has written a very interesting post on being a community bumble-bee. (Source can be found here)

He goes on to explain how he has visited many meetups all over Europe and the big chunk of information and experience he has learned from them.

He tells us about a selfish approach to organizing meetups:

When one teaches two learn

(apparently attributed to) Robert Heinlein, source

I share this feeling of learning while teaching, as long as you reflect and analyze (e.g., hansei or reflect as you work). I also try to apply it to my meetups.

As a funny note, he said this cross-pollination has crystallized in as many ideas as to fill three books.

Today we’ve discussed about code reviews on this open space

Notes

These are my notes, in no particular order:

• reduce information silos all around the company, as everyone [technical] can participate in these events
• raise the “just arrived” people’s knowledge [Difficult to hit the ground up and running, but these code review sessions can help]
• invest one person as ‘sheriff’ for the sprint: they will take care of static analysis tools (such as sonar) and continuous integration (CI; such as jenkins). They will make sure others follow the working agreements
• In the academic environment, some teams do share their patches via mailing lists and this makes it much slower to adapt and review changes [As compared to an on-line sharing system - like web-based interfaces to distributed version control systems] As this team doesn’t have a CI tool, they must test it / try it manually before reviewing the code.
• Pair programming does not remove the need for code review [This has been surfaced twice]
• Your work is not more important than your team members' one. [Related to not having time to code review]
• Do code reviews include architecture? [We’ve agreed that the architecture to some degree should be discussed before code reviews]
• “Troll review”
• Anyone can veto pull requests [By opening a question; do not allow for pull requests to be closed with open questions]
• A 15-minute time slot everyday to code review [As code hygiene; Done right after lunch, breakfast or just before leaving, when you’re tired]
• Code review tasks have higher priority than other tasks [Do not take other tasks if there are code reviews to do]
• Code reviews put a lot of pressure so people learn and the knowledge level equalizes across the team

Conclusions

My conclusions, even though some of them were not shared by everyone:

• Most of the people approve of code review practices: either they are doing them or are trying to apply them at their clients. (Warning: this was a code review meetup, so there’s a bias: people not interested in them won’t come). No one was against doing them.
• Code reviews have a cost, although it is beneficial to do them
• Should your teammates not want to participate in the code review after agreeing on doing them, appeal to their professionalism / accountability, then to their time (stated before), then troll them: after a few (healthy) trolling code review sessions, people will feel more comfortable reviewing and being reviewed. Special mention to Miguel who coined (?)¹ the term: troll review.
• Great way of equalizing the (technical) knowledge level within the team
• Great way of reduce information silos across the whole company
• They can be fun if you do them properly
• The need for code reviews do not disappear when pair programming: as long as you have a personal attachment to the code, you might not see its defects.

Your own

Should you have any conclusions to share, please add a pull request to this repository or do it as a comment.

Yesterday we organized a TDD meetup at the FIB - Barcelona School of Informatics UPC, within Barcelona Software Craftsmanship sponsored by the Junior Empresa d’Informàtica. The meetup started at 9:00 until 18:00, with a one-hour pause in the middle.

Where

• Please make sure the meetup space (e.g., classroom, meeting room) is available and ready to be used at least 15 minutes before the meetup starts
• The organizer and the event host should be there in advance to prepare the physical environment (chairs, wifi, beamer, etc) as well as mentally: getting comfortable with the space, loading the presentation, prepare the speaker notes, etc.
• Plan for the worse and hope for the best: in this particular meetup, the beamer was not available, so the host gracefully lent us some 23 inch screen as a second monitor.

What

• The speaker should have had already decided what they are going to cover on the meetup and not deviate much from this. Leave some empty buffer space at the end because you will cumulate some deviation during the day.
• Of course, have the slides ready if you plan on using them
• I prefer having more conversations during the meetup rather than a masterclass-style one. The organizer(s) should act as conversation moderators, often guiding the conversation where (they think) it is most useful. Sometimes, it is a good idea to interrupt the conversation when someone is getting bored or losing focus¹.
• Be prepared to ask to your attendees what do they want: they are your target
• Please ask to your attendees to bring their laptop with git, dependency manager, IDE / editor, test double framework installed. Otherwise, most of the first session is invested in downloading / configuring these.
• Please try to be communicative / funny in some way. This makes the slides easier to understand

Meetup details

• We did two sessions of slides:

  • Introduction to TDD
  • TDD on a daily basis: learn TDD for a greater good

• We did three katas:

  • LinkedList: source. Originally by Dave “Pragmatic Dave” Thomas
  • Password: source. Taken from Manuel Rivero, also seen on a Carlos Blé workshop
  • Bank Kata: source. Originally from Sandro Mancuso

• The format was this: the first set of slides, the two first katas, some discussion, then lunch; coffee (mandatory); the second set of slides, the third kata (done by them), later done by me at the beamer, explaining the situation and my mental process.

Useful feedback

• About the event:

  • One 8-hour event is much more effective / efficient that 4 2-hour ones
  • No one complained about the lack of beamer. So don’t worry too much if your host doesn’t have one, as long as everybody can get close to the (big) screen.

• About the LinkedList kata:

  • This, as a first TDD example was too complex. Getting into TDD with classes, and several functions at the same time might be difficult.
  • Too academic. This is an example you will usually never implement yourself, as there are libraries who provide it. Therefore, not applicable.

• About the Password kata:

  • They graded this kata easier than the linkedList
  • Start with this as it is only a function
  • This has didactic value as there are some gotchas with this kata
  • More likely to be implemented by yourself, as most systems require some kind of user authentication

• About the Bank kata:

  • More resembling of a day-to-day problem
  • This is a difficult kata if you haven’t learned about mocks / test doubles
  • Interesting interactions between objects

• For me:

  • They liked both the format and the speaker (a.k.a., me)
  • They thought this meetup was well prepared in advance

• My own feedback:

  • It is difficult to ask the attendees to rate their own level or for you to rate it. I thought the linkedlist example would be so easy they would finish it in half the allowed time², but it wasn’t this way
  • The productivity level varies hugely from person to person. There were some pairs that dug thoroughly on the problem and others who got stuck (sometimes with the language). Even though both types of pairs were working hard on the proposed problem
  • We still haven’t solved the problem with reservations: many people book a seat on the event but later won’t come. This makes other (interested) attendees to not have a seat.

Should you want to, please share your feedback / comments via the comments section below or sending a pull request to this repository

I’ve built a small maven module, to be used directly with cucumber. You can fork the repository here

This is the setup I’ve proposed for the meetup “BDD Cucumber kata (gherkin + code)". Will see if this code is successfully used by the ~40 participants in a couple of weeks

(Quote from the README.md):

This maven project has been possible due to Thomas Sundberg and this post

Should you want to, there’s a tweet to thank him the effort: [tweet intent here](https://twitter.com/intent/tweet?text=@thomassundberg thanks for the cucumber bdd tutorial! Will be using it from @agilebcn;Keep up the good work&url=https://thomassundberg.wordpress.com/2014/05/29/cucumber-jvm-hello-world/)

Happy katas and happy bdd’ing!