In this lexical scope, TDD by example is referring to this book, available on Amazon
The TDD cycle
Altough Kent Beck in his book Test-Driven Development by example explains in “Part I: the money example” that one should
quickly add a test;
run all the tests and see the new one fail […]
Kent Beck
Implying that the TDD cycle starts with the red. Later on he explains that the cycle continues with green and refactor and back to red.
But I’ve been hearing for a while that there’re some useful refactors to be done before introducing new code. Rings in my head but the only example I have is Xavi Gost’s “La economía del refactoring”
Refactoring
Let’s take a look at the definition of refactor (found here):
[Refactoring] is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
Martin Fowler
I’ve found some info on stackoverflow about the subject. The currently accepted answer points out some interesting comments:
- Do not refactor on red. Always a good reminder
- If you are refactoring for introducing a feature, how much refactor is enough? This is speculative development, possibly taking much time from needed development
The last point is the one that interests me the most:
- Your refactoring might not be where you’re going to introduce new production code (spatial caché)
- You might end up introducing features after a few hours/days of refactoring, therefore losing focus on the refactor you did and why (local caché)
- Given that I’ve already “cleaned up” this, I could also go somewhere else (slippery slope). Heard from Xavi Gost at the CAS2014 at his talk La economía del refactoring
No está justificado hacer cambios fuera de la rebanada.
Roughly translated to “It’s not justified to change outside the bread slice”, as Xavi was referring to software as sliced bread instead of layers, vertical rather than horizontal
Should you do it?
- Doing it would be a good thing, as long as you know in advance what will be affected by the next feature.
- It can allow for less refactoring at the end of the cycle. This is not about duplication but refactoring to patterns. There might be a gain in refactoring to a pattern before introducing another feature. An example might be adding a new strategy when it’s currently coded as if-then-else
- The last responsible moment might be before or after introducing the feature. You decide.
- Work less as there’s no need for adding new cases to old structures and then simplifying
Should you not do it?
- Foreseeing the future is difficult, therefore you might end with unused development, as it is speculating
- Related to the last point, you might end refactoring in the wrong places. There’s no current business value to it.
- Not useful on first round of a new feature, you can use a lambda transition to the red again. But then, this is not a general pattern, only applicable to a big percent of cases.
Conclusions
Short answer: it mainly depends on your environment:
- You: experience, common sense (sadly) —another post coming—, benefit/time-wasted ratio
- Your project: how tight are deadlines, how critical that code is, the team’s pressure
Long answer: Yes, as long as:
- You realize there is a fine line between fixing code and rewriting code (Egoless programming #4). Don’t be a lone enforcer
- Strictly follow the boy scout rule but only around your campfire, not outside of it.
- You know your domain, pitfalls and team well
- You want to test this hypothesis and post an answer
Sources
One month ago (on November 15th) I facilitated my first Global Day of Code Retreat at eBay Enterprise International and had such a blast. Link to the event (Spanish)
Some thoughts
After a month of thinking about it, here are some thoughts:
-
This year’s GDCR was quite different that last one’s:
It’s OK: do not strive for repeating the same each year
-
Heat map (in several dimensions): TDD x language
Usually meetups have a clear goal, for the limited amount of time they run (see another bullet point).
This single goal can span across multiple skill sets (e.g., TDD and language specific), therefore we did a two-dimensional heat map: first dimension is TDD skill level and second dimension (discreet) would be language you master
Example can be found here
-
As a facilitator, have a clear goal for the meetup, even though you don’t need to share it with the assistants
Mine was to have fun and introduce some people to TDD
I shared the goal with the attendants because I wanted to explain the purpose of that day to newcomers.
Also, as a result of that day, I’ve discovered some very motivated people in our host (eBay). Personally, I’d like to continue doing meetups with their developers.
-
You need a mix of more seasoned attendants and more unexperienced ones.
This way, the knowledge is being transferred both ways; not only about the language but about strategies, patterns, shortcuts & editors, languages, etc
If doing TDD in these events, it’s even more important to mix people, as it’s difficult for an unexperienced pair to start doing TDD for themselves.
-
You should only do your job as facilitator
Let others discuss, ask and answer questions. Your job should be as thin as possible. Don’t try to answer too many questions
There will be attendants with more experience / expertise than you (most of them were in my case), so don’t strive to teach them but to manage the discussions to the right place
Be strict about timing but find the balance. Sometimes it’s useful to invest more time (~5 minutes) to a rich discussion and then reduce the next iteration.
Many people will complain about having to delete their code the first time. Explain to them that’s part of the game and don’t give in. The following iterations most of the people won’t complain anymore
Last but not least, have fun!
Some critiques
We organized the event a little bit late
-
The difference from last year (December) vs this year (November) was relevant. We were expecting to do it later so it surprised us.
-
Due to that, many people couldn’t come and I’m sorry for it
Conclusion
We totally, definitely should do this more often.
You need to reinvent yourself for every global day or people will stop coming
Quoting the book,
Why is programming fun? What delights may its practitioner expect as his reward?
First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design […]
Second is the pleasure of making things that are useful to other people. Deep within, we want other to use our work and to find it helpful. […]
Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. […]
Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.
Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from the pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creating are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this very tractability has its own problems.)
Frederick P. Brooks, Jr in the “The Mythical Man-Month”
Update: J.M. Beas did an awesome take on this subject on his blog (Spanish)
This is a free application I use quite often: pocket
They promote it as “When you find something you want to view later, put it in Pocket.”
I really use for that. Once you install it in your phone, some handy shortcuts appear both on Chrome for saving the page and on twitter when you hit the “share” button.
It is especially useful when you’re on the tube and have no connection, as pocket saves an offline version of the page (warning: this doesn’t work for video sites like youtube)
This year’s edition of the CAS 2014 has been awesome. There were several tracks:
- Enterprise Agile
- Collaboration, Culture and Teams
- Delighting Products
- Agile+
- Development Practices and Craftsmanship
The last one is where I spent most of the time.
The schedule
The first day:
The second day:
Some thoughts
The conferences were awesome, but I’d preferred if most (if not all) were in English so this conference can attract more international speakers
There were 600+ people in the CCCB. That was only possible due to all the volunteers, organizers, caterers and the assistants.
More info
You can find more information on the official website and on twitter using the hashtag #cas2014
This is the obligatory “Hello World!” post
To get here and create your own blog using octopress, follow the
instructions below:
- Install ruby, as explained on the guide
here
- I’ve used Ruby 2.1.5p273 (2014-11-13 revision 48405) [x64-mingw32]
(
ruby --version)
- Configure your blog. See
here
- Install octopress:
rake install
- Start the server with
rake preview. You should see a basic
template (CSS) with your blog name, the author, etcetera
- Create your first post.
rake new_post["Hello World!"]
-
Refresh the browser and see the new post appear
-
Edit the .markdown file in “source\_posts” using a markup editor
-
Execute rake preview to see your first post (this)
-
Execute rake setup_github_pages for every computer you want to
publish from
-
Execute rake generate && rake deploy. After a few minutes, you
should go to
.github.io to find your new blog in there
-
Happy blogging!