The long way through Software Craftsmanship

TDD microexercise: Tire pressure

Mar 31, 2015 - 2 minute read - Comments - microexerciseprepared-katasessionscbcn

Yesterday, Manuel Rivero and I facilitated a workshop using the tire pressure TDD microexercise. (More microexercises can be found in this category, also here)

We scheduled the session as follows:

  • 10 minutes introduction to the exercise
  • 10 minutes to download the code and take a first look
  • 10 minutes explanation about the exercise, what the problem is, etc
  • 30 minutes for the attendees to explore the solution (on their own)
  • 10 minutes for commenting the explored solutions, comments about it
  • 40 minutes of prepared kata format
  • 10 minutes of final explanations, questions and answers (Q&A)

Total: 120 minutes or two hours, approximately

We decided that one would be mostly at the keyboard and the other mostly explaining. This allows for the speaker to introduce some concepts while the driver is performing a larger refactor / step.

Some of our own feedback:

  • Have the kata prepared, clear all your doubts before doing it live
  • Be very specific about the goal of the kata: the narrower the focus, the more we will learn
  • If necessary, exercise your shortcuts / practices one last time
  • Set up the font as big as needed. Even remove some whitelines (present in your usual code) so more text can fit in the screen.
  • It was very useful for us to have a small script of what we would perform: what was the idea, where to stop to explain things, etc
  • A prepared kata is a show (like a movie), so the dialogs between the performing pair are important. Do not be afraid to tell the reasons why you did this last refactor.
  • Answer the questions as you go, do not wait until the end of the session

Some feedback we received:

  • It would have been useful to do a recap at the end of the session, to refresh the most important concepts
  • In general the session was good, they were satisfied with the techniques shown there
  • The exercise was concise and small, perfect for two hours' time

Many thanks to all the attendees and to Manuel: I learnt a lot from the session and renewed my energies to keep doing these workshop sessions. Also thanks to Luca Minudel for writing these awesome exercises.

Books read in 2015Q1

Mar 31, 2015 - 1 minute read - Comments - bookreading2015Q1self-study

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

Books started, not yet finished (WIP):

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

Growing software according to the season

Mar 29, 2015 - 3 minute read - Comments - growing-softwarebuilding-softwareseasonagriculturegardeningsoftwareembedded-tweetgoos

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.

Meetup cross-pollination

Mar 25, 2015 - 1 minute read - Comments - meetupcross-pollinationbumble-beeale14agile-lean-europe-2014

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.

Open Space: Code reviews

Mar 16, 2015 - 3 minute read - Comments - agilecode-reviewtroll-reviewcraftsmanshipnotesexperience-reportteambarcelona-software-craftsmanship

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 (?)1 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.


  1. after searching some ten minutes on the internet, there are only a couple of questions on meta.codereview stackoverflow, but not related to this. Update: In here, Vaibhav Mallya talks about a #trollReview, related to code. So, unfortunately, Miguel, you’re not the first one. But there are fewer than 10 results on twitter. ↩︎

TDD Meetup Retrospective

Mar 16, 2015 - 4 minute read - Comments - retrospectiveexperience-reportmeetuptddtraining

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 focus1.
  • 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:

  • 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 time2, 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


  1. a good indicator of this is body language or position and whether they are doodling on a paper sheet. ↩︎

  2. I did prepare against this adding more possible requirements to the kata, although we finally didn’t use them ↩︎