The long way through Software Craftsmanship

A legacy code introduction

Feb 21, 2015 - 2 minute read - Comments - quotehypothesisclean-codeuncle-bobrobert-c-martinlegacy-codetiger-team

This is one of the best legacy code introductions I’ve seen: The Grand Redesign in the Sky Eventually the team rebels. They inform management that they cannot continue to develop in this odious code base. They demand a redesign. Management does not want to expend the resources on a whole new redesign of the project, but they cannot deny that productivity is terrible. Eventually they bend to the demands of the developers and authorize the grand redesign in the sky.

The use of power tools

Feb 18, 2015 - 6 minute read - Comments - power-toolsapprenticeship-patternschoose-your-own-adventurebig-o-notationalgorithmprotipright-tool-for-the-right-jobunix-tools

I’m currently reading the Apprenticeship patterns book, out of order (explained here: TODO). I’m writing down the read chapters in a text file, to measure progress and also be able to backtrack if necessary. This also makes reading the book a “choose your own adventure” After reading approximately half the chapters, the navigation wasn’t so easy using only the “see also” part. So I decided to break free from that constraint and start reading other chapters.

Open discussion: Behaviour-Driven Development

Feb 15, 2015 - 2 minute read - Comments - bddopen-discussionbehaviour-driven-developmentjbehavetraining

This week we had a great discussion about Behavior Driven Development (BDD). We have explained it as a way of developing software based on requirements, via automatically tested specifications. For more information, see the wikipedia’s article on the subject I forgot to mention that this is the perfect start to TDD, as this is usually called the double-loop TDD. See a post on it on coding is like cooking

Implementing BDD at a client

Feb 9, 2015 - 1 minute read - Comments - bddgrunt-jobbehavior-driven-developmentsweep-the-floorapprenticeship-patternsjbehaveretrospective

This was a low-hanging fruit as a team member who specialises in QA complained about testing in the last moment during the last sprint’s retrospective. Did the grunt job of connecting the dots and configuring the maven project (using jbehave). Also, got the inspiration from a tutorial. Announced it only as it was in place and QA approved of it This grunt job clicked with Sweep the floor Let’s see how the sprint goes and what are the pain points during this sprint

Open discussion: On code reviews

Feb 7, 2015 - 3 minute read - Comments - internal-trainingopen-discussioncode-reviewpair-programmingtraining

At a client, I organized an open discussion on code reviews. We had a great conversation. The main idea was to discuss about it and share the ideas each one had. I didn’t want it to turn into a masterclass (see the white belt) Benefits These are the main benefits we saw in it: Increased trust Learning from others, other approaches Less defects, more quality Increased bus factor, decreased information silos Also: Getting out of your comfort zone Communicating more often (code style, edge cases, complaining, etc) Pair programming Then we discussed about the topic of code reviews and pair programming:

Pairing with junior developers

Feb 3, 2015 - 2 minute read - Comments - pairingpair-programmingexpertisejuniorseniorexperienceapprenticeship

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.