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. […] Brooks, F.

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.

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.

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 In this double-loop TDD, the first thing is to create a BDD scenario, run it (red-1), create a unit test that reflects this red (red-2), pass it, refactor; go to red-1 as many times as you need, doing TDD cycles.

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

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: