The long way through Software Craftsmanship

Maven module Base for cucumber in java

Mar 10, 2015 - 1 minute read - Comments - cucumberbddjavamavenrepositorymeetupagilebcn

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!

Brown-bag session: maven

Mar 6, 2015 - 1 minute read - Comments - maventooljavatrainingbrown-bag-sessionclient

Yesterday we did a training about the maven tool. One of the team members explained to us some topics including:

  • lifecycles
  • profiles and how to create one
    • slowTests for integration tests (this client only)
    • downloadJavadoc
    • downloadSources
  • convention over configuration
  • scopes of the dependencies (test, runtime, compile, provided)
  • tricks about the tool:
    • order of the dependencies (especially junit, hamcrest)
  • plugins and how to build one
  • destination folders
    • target, classes, test-classes, etc

Note: this post was created a posteriori, with the original date

Mob programming String calculator kata

Mar 3, 2015 - 3 minute read - Comments - mob-programmingtrainingtddkatastring-calculatorpair-programming

Last Friday we did a kata1 using a projector the string calculator 2 using pair programming, TDD and some mob-programming for the last refactoring.

We used a projector (beamer) so everyone could see it. I tried to take really small baby steps but the adding part was done in ~6 cycles3

We’ve all learnt about shotcuts, live user templates for the IDE 4, TDD methodology, other ways of tackling the problem, how to refactor as a group, clean code, etc

These sessions are necessary to share some knowledge among the teammates and have another chance of doing code review, releasing some pressure from daily practices or bad abstractions / designs (that will be taken care of in the future)

We’ve had such a great time, learning together, that would be a candidate for a weekly interaction.

Mob programming is such an eye opening practice. It forces you to reconsider your previous dogma and to understand the others' positions. Wikipedia reads “early use of phrase […] was made in ‘Extreme Programming Perspectives’” but this practice is practiced by some, such as Carlos Blé, Sandro Mancuso among others; also at the Software Craftsmanship Barcelona 2013 and 2014 and the SoCra Canaries 2015

One goal

Our goal for this session was to practice TDD and baby steps, so the team can improve its ability on these skills.

In any case, my objective for the katas (or deliberate practice) is not to get there as fast as we can but to improve our automated routines. This can affect our daily performance, as it becomes natural. It is not about the getting to the destination but enjoying the path along the way. In this manner, you are not so hurried up about a slow train but enjoy the views across the window.

It was good that QA people in the team came to the session. He even participated with some tips / implementations during the refactors. Always fruitful to discuss (and learn) mixed skills (QA / dev) from the other side of the wall

Conclusion

I still haven’t mastered the recipe (algorithm) for knowing when it is a scaffold and when it’s time to refactor using “replace algorithm”. For know, I just use the three (3) rule and a bit of gut feeling on the side. The bad thing is that this can not be easily taught to someone else. Just learnt by osmosis and practice.

  1. matching none of the styles explained in here ↩︎

  2. This is a very good beginner’s kata, created by Roy Osherove. Can be found here ↩︎

  3. One piece of feedback I received is that I talk too much while coding, as these 6 cycles took us about 45 minutes, total ↩︎

  4. There are some for IntelliJ IDEA, Eclipse too ↩︎

The purple wire

Feb 24, 2015 - 3 minute read - Comments - debuggingdefectpurple-wiremythical-man-monthquotefred-brooks

A quote from the Mythical Man-Month:

Chapter 13: The Whole and the Parts

[…] In System/360 engineering models, one saw occasional strands of purple wire among the routine yellow wires. When a bug was found, two things were done. A quick fix was devised and installed on the system, so testing could proceed. This change was put on in purple wire, so it stuck out like a sore thumb. It was entered in the log. Meanwhile, an official change document was prepared and started into the design automation mill. Eventually this resulted in updated drawings and wire lists, and a new back panel in which the change was implemented in printed circuitry or yellow wire. Now the physical model and the paper were together again, and the purple wire was gone.

Programming needs a purple-wire technique, and it badly needs tight control and deep respect for the paper that ultimately is the product. The vital ingredients of such technique are the logging of all changes in a journal and the distinction, carried conspicuously in source code, between quick patches and thought-through, tested, documented fixes.

[…]

Brooks, F. - The Mythical Man-Month

This purple-wire the author talks about is extremely important even in the current age as the whole team should not be blocked by a single defect.

What I usually do is a commit containing a quick fix (purple-wire, scaffold, hackish if, etc) on a bugfix branch, push the changes so jenkins can verify that this purple-wire didn’t break any other case. Then integrate this bugfix into master if required1. If this affects develop branch of other developers, also merge into develop and or feature branches.

On the other hand, in my opinion, fixing the defect should include an unit test so the defect does not reproduce again. If this is not reproducible through an unit one, escalate test levels (unit, integration, end to end, etc) until a suitable one is found.

Once that applying the purple-wire is done, I checkout the last version where the defect is to be found (usually right before the bugfix branch) and create this test necessary to reproduce behavior. Only after this defect is found I fix it. Otherwise, I think the root cause might be in a different place and, therefore, fix a non-existing defect, effectively introducing a regression.

This test also serves to reproduce that the corrected behavior is not introduced anymore into the system.

As an ending phase for the defect, replace the purple wire with the new code and, after passing all tests, merge to master, develop and feature branches.

  1. If the found defect is not business critical, I try not to merge to master the purple wire, just leave master pointing to the defect and the bugfix branch with the solution. This bugfix branch will be deleted when a more stable fix is found. ↩︎