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

Yesterday at the clojure meetup we¹ did the mars rover in clojure and today I’ve tried my hand at it again. Original, from the three of us here and my results here

Last Friday we did a kata¹ using a projector the string calculator ² 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 cycles³

We’ve all learnt about shotcuts, live user templates for the IDE ⁴, 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.

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 required¹. 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 a 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.

I’ve just written a new kata, about a persistent linked list.

It is using the same project as for the linked list kata.

For now, only the add, contains and size methods are implemented.

If you have any comments or code review, please let me know

The toolsmith

Frederick P Brooks, Jr quoted / explained a theory explained by Mills and Baker¹ 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. - The Mythical Man-Month, chapter 3: The Surgical Team

(Text between square brackets is mine)

The author goes on to explain the job descriptions for the surgeon, copilot, administrator, editor, secretaries, program clerk, toolsmith, tester and the language lawyer.

The one that will be covered in this post is the toolsmith:

The toolsmith. File-editing, text-editing, and interactive debugging services are now readily available, so that a team will rarely need its own machine and machine-operating crew. But these services must be available with unquestionably satisfactory response and reliability; and the surgeon must be sole judge of the adequacy of the service available to him. He needs a toolsmith, responsible for ensuring this adequacy of the basic service and for constructing, maintaining, and upgrading special tools –mostly interactive computer services– needed by his team. Each team will need its own toolsmith, regardless of the excellence and reliability of any centrally provided service, for his job is to see to the tools needed or wanted by his surgeon, without regard to any other team’s needs. The tool-builder will often construct specialized utilities, cataloged procedures, macro libraries.

Brooks, F. - The Mythical Man-Month, chapter 3: The Surgical Team

Even though the chapter reads a bit outdated, especially with the part about genders and methodologies (i.e., waterfall), the part about roles is interesting. The surgical team, as the author presents will be composed by 9 1/2 (nine and a half) as the language lawyer can be shared among two or three teams.

Day to day practices

So, one full-time job is to build tools to service the surgeon and the copilot (1:8,5 ratio), or approximately 12% of a full-time position.

These tools can make the surgeon and the copilot more effective, ranging from a single digit percentage to orders of magnitude in other tasks.

As agile teams no longer have a toolsmith and the scrum master is not necessarily a technical expert who can build tools for the whole team, the tasks of creating tools must be taken care by everyone. No one better than yourself can know your needs and tailor solutions for them.

The only downside is you have to invest ~5h (for a full time position) per week into creating and polishing tools for your work: it is a need for achieving more productivity when working.

Nowadays that IDEs are configurable, this time might be invested on learning more advanced features as other shortcuts, refactoring techniques, other design patterns, etc. I like having my own live templates (see description), especially for tests, as I saw on the Crafting Code workshop by Sandro Mancuso

It may also include other activities as setting up your bash alias, cleaning your desk, trying a new UML diagram modeler, etc. Anything that improves the productivity of your main task.

If we consider our experience and knowledge part of our tools (as we are knowledge workers), training could be considered part of polishing our tools. Short, daily or weekly training sessions (even internal) can make a great impact on breadth (not depth) of knowledge among your teammates. This shallow knowledge can open doors for more knowledge to be gained outside of company time, or used to practice and test other methods.

This training is so useful for everyone (“when one teaches, two learn”) that I recommend my clients to do it. This has helped them cope with changing technologies, knowledge transfer and even some team building.

Company provided or not?

Should the company provide for this time to improve? Although I don’t know the answer, it would greatly affect the programmers' productivity to do so. I would say, provide this time as long as what is produced is useful. How do you measure useful? This is a subjective opinion, so it depends on each one.

Some companies acknowledge that this is so important as to invest part of their resources (0-2 hours per week) into training.

Either way, should your company provide it for your or not, you are the one in charge of your career (from Mancuso, Software Craftsmanship - now called The Software Craftsman). If you are not allowed to invest company time for your own benefit, you could use some of your personal time to do so. It is not required, but you will soon enjoy its profits.

Examples

• Every sprint, one of my clients (as of 2015-05) wants to review the work done using some slides and a live demo. The ‘sample’ slides with the format, layout is useful. Everything that should be replaced (timestamp, contents, etc) is marked with a TODO
• Every day, I commit plenty of times to the control version system (i.e., git). I have an alias for commit, diff, status, etc, that saves me some keystrokes on the most common commands
• See the post “A basic working environment”
• Deployment, even on local, is automated: a script for getting the latest branch, develop or master code, build the Docker container, start the docker image, notify me the code is ready
• Pipeline: I have a pipeline, in local, where I can push and the tests will be executed automatically. If the build fails (usually BDD tests), I can push -f without affecting to the repo history.

Mills, H., “Chief programmer teams, principles, and procedures,” IBM Federal Systems Division Report FSC 715108, Gaithersburg, Md., 1971.

Baker, F. T., “Chief programmer team management of production programming,” IBM Sys. J., 11, 1 (1972).