After reading this blog post, here are my thoughts:
WARNING: the post was about how to do it, these reflections are on a more philosophical level
This is a controversial topic, as:
- You cannot discern how much or little the other person knows more than you. I cannot find the reference anymore, but it was a to the tune of “once the other person’s level is higher than yours, you cannot know how much”
- There are different knowledge areas. Yours and theirs might overlap on some areas, but not completely. So they may be experts on an area that is not useful to the technology you’re currently using.
- Different people have different passions and motivators.
When and where are you a junior and a senior?
- Does it depend on each job?
- Is it on each product you work?
- Is it on each team?
“when you join a new project you are starting from square one”
D. Hoover, A. Oshineye in the chapter Sweep the floor, Apprenticeship patterns
Related to the amount of senior people, is there only one senior per team?
- Can everybody be a senior? If we assert this is true, what about “if everything matters, nothing matters”. Does that mean that everyone is senior or there are different levels of seniority and we call “the senior” the one on the top of the list?
- Who choses the senior within the team? Is it self-organized, self-chosen? Do the people chose one? Is a shared responsibility, as each one masters a (possibly different) subject?
Food for thought.
What do you think about it?
I’ve read this book Diseño Ágil con TDD (Spanish) by
Carlos Blé from cover to cover,
when previously I had only read the theoretical parts (Part I and Chapter 12 in Part II).
It’s worth noting that this is the first TDD book in Spanish (I haven’t found any book in Spanish predating this one - also backed by the author; published in January 2010) and, as such, there are some translations that could be improved. Not that it makes it more difficult to read. Sometimes it’s a good idea to roughly translate concepts into English and then you’ll understand the point.
First part
The first part is very interesting, a theoretical introduction into TDD, ATDD and Agile methodologies. Points to some good books as a reference (e.g., Growing Object Oriented Software, Guided by Tests; Working Effectively with Legacy Code; Refactoring; etc)
He explains the TDD algorithm (chapter 2) and the ATDD one (chapter 3). These two are maybe the two most important ones on the book. Should you read only a part of this book, I’d recommend to read the motivational intro (the fable on the preface) and these two.
He gives excellent pieces of advice who, correctly applied, would set the basis for good software development, such as SOLID, Object Oriented Design (OOD), Inversion of Control (IoC), etc. (See chapter 7, “Diseño orientado a objetos”).
There’s a chapter (number 6) on “Mocks and other test doubles” (translation is mine)
Second part
The second part, as many other books where the source code is printed, was dense for me. Other books, such as GOOS, show differences in content with bold typeface, to ease the reader’s task. In my opinion, it would be useful to color the diffs, show them on the left and right, or even show the raw diff (e.g., +++
---
). I’m envisioning a typing program as LaTeX where you could specify a commit with its parent and a range of lines to output.
The second part is written in C# and python, to show a TDD session with him. Warning: it’s much better in person than reading his book!
The chapter 12 is a set of antipatterns you might find after starting with TDD. Even after you keep practicing TDD for a while, you will not get rid of these smells. Highly recommended.
There’s also an appendix on Continuous Integration, although there are better books for this.
Conclusion
Recommend this book if you are starting with TDD, or you are more advanced but it’s difficult for you to read in English.
Always good as a refresher to read the theoretical part and the antipatterns
PS: This book is free to read, published under a Creative Commons license (don’t know exactly which one)
After reading (in a specific order - below) part of the patterns in Apprenticeship Patterns,
I stumbled upon the “Your First Language”
First of all, the illustration with the baby reading a Java book is priceless.
Having said that, I came to the realization that you might not know a paradigm but just an implementation
(e.g., you don’t know about Object-Oriented programming but just about Java), in the same fashion as you could not know about LISPs but only about an implementation, such as clojure.
Also, clicks with the idea of “code to interfaces, not implementations”. Does it also click with you?
PS: What a great book this is. I’m reading it as explained here
PPS: you can read it online for free, here
Some weeks ago I listened to some podcasts from BastaYaDePicar (episodes 1 to 8) and now I’m listening more (9 to 10). I really recommend these to you, and I imagine that the newer episodes (also new format) will be interesting too.
They’re in Spanish and narrated by Sebastian Hermida
Following a team member’s recommendation, I recently started a repository to save all my useful snippets.
I’ve decided that the examples should be designed guided by tests or at least to have a working example exercised by tests. Also, that I should not reinvent the wheel and use as many open source libraries as possible, reducing the amount of code I have to write myself.
Ideally, every snippet should be a maven project (where applicable) and be imported as a small library, therefore being able to reuse the functionality incrementally across projects.
For the time being, I’m saving my snippets into a private repository and later I might decide to publish it for common usage.
Manuel Rivero and I did a subset of the bank kata, proposed by Sandro Mancuso.
We’ve used java (mockito, hamcrest, junit), outside-in TDD. The code is spread among several sessions. We have not committed after each step, only at the end of the session.
The source code is on github
You can read Manuel’s take on the kata on his blog