The long way through Software Craftsmanship

Polishing your tools

Feb 22, 2015 - 5 minute read - Comments - toolsmithpolishcraftsmanshipcraftsmantrademythical-man-monthsurgical-teambrookscareerwho-owns-your-careerfred-brooks

The toolsmith Frederick P Brooks, Jr quoted / explained a theory explained by Mills and Baker1 around 1971-72: Chapter 3: The Surgical Team […] but the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him[her] every support that will enhance his[her] effectiveness and productivity. […]

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: