The Code Freeze 2021 virtual conference culminated in a two-hour mob programming (a.k.a. ensemble work or samman) workshop. Seventy-four participants worked in 17 groups, each facilitated by an experienced mobber. Facilitators included such luminaries as Woody Zuill, Llewellyn Falco, and Jeff Langr, among lesser lights.
Continue reading Code Freeze 2021: Mob Programming Workshop
Tag: tdd
Pain today, gain tomorrow?
Many of us who try to help others learn and use good software development practices have made the case that if only a person would try a recommended technique and get used to it, eventually they would see improvements in code quality and a reduction in delivery time, and probably easier maintenance of the code base, too.
It’s generally true that when we begin to learn a new skill we work more slowly than we will after we’ve learned to apply the skill effectively. This seems to make many people hesitant to try anything different than their current practices. The idea of slowing down temporarily in order to improve “later” is hard to accept. People have difficulty accepting any short-term cost in order to achieve long-term gain.
But what does it mean…eventually or later or after a while? When is “eventually?” How much “later?” How long is “a while?” People are afraid the temporary slow-down during their initial learning curve will have too much impact on delivery time, or will take too long to overcome.
Live online training: What’s different about it?
No one can predict when the virus situation will pass; but we all know it will pass. The question is, what will we have done in the meantime to position ourselves for new opportunities when the economy rebounds?
This is not a time for us to roll up and hide in our shells like frightened armadillos. It’s a time for us to build our knowledge and hone our professional skills, to prepare for the new opportunities to come.
I suggested recently that companies need to use this time to regroup, reset, and get ready for the economic upturn that will surely follow the present crisis, rather than just shutting down and hoping things will get better soon.
Hope is not a plan, and neither is releasing your most valuable and hardest-to-replace assets: Your people. On the contrary, this is the time to enroll technical staff in training, so they will be ready to meet the challenges of the new economy that will emerge from the present downturn.
Continue reading Live online training: What’s different about it?
Code Katas
A code kata is a formulaic or choreographed way to practice programming skills. Many katas can be done in different ways to achieve different learning goals. Others are designed to help us internalize a sequence of steps to address common programming problems we encounter in our work.
In 2012, writing on an blog I used to maintain, I attempted to explain why we practice code katas. Based on observations of coding dojos and similar meetups in the years since then, it seems to me people still don’t understand the purpose of a code kata, or how to use katas to build skills.
When I searched for an explanation of how katas are used in martial arts, I discovered a very good explanation by martial artist Martin Jutras, on the Karate Lifestyle site. One thing that makes his explanation particularly relevant is that he addresses common misconceptions about katas. I’d like to quote from that site now, and correlate Jutras’ observations about martial artists with my observations about programmers, in the hope of clarifying the role of code katas in our professional development.
Continue reading Code Katas
The Curious Incident of the Magnetic Scotty Dogs in the Night-Time
Long, long ago, in February of 2020, Joshua Kerievsky of Industrial Logic fame published a blog post entitled, “A Tale of Two TDDers.” In it, he described a production issue which he said was based on real-world experiences in a real code base. He described two team mates, David and Sally, who took very different approaches to solving the problem.
Although based on a real incident, the story in this blog post is not the actual tale; it’s a contrived version in which David and Sally separately solve the same problem two different ways. David used a test-driven approach and took several hours to refactor a bunch of related code. Sally pushed a quick fix into production and the team immediately added the missing test case(s). Of course, in real life the team solved the problem just once. But Josh wanted to set up a question for readers: “Which programmer would you prefer on your team?”
The post generated quite a bit of enthusiastic discussion. So much, and so enthusiastic, that just 6 days later Josh posted a follow-up post, “One Defect, Two Fixes” to try and clarify. He mentioned the first post had “generated a lot of interesting discussion, some of which bordered on deep misunderstanding.”
Continue reading The Curious Incident of the Magnetic Scotty Dogs in the Night-Time
Against TDD
Test-Driven Development (TDD) is a tool. To get value from a tool, it’s necessary to:
- choose the right tool for the job; and
- use the tool properly.
Circa 2019, there are numerous debates about whether TDD is useful. It seems to me many of the arguments against TDD boil down to one of the following:
- trying to use TDD in situations where it is not the right tool for the job; or
- using TDD improperly.
Choosing the wrong tool or using a tool improperly are certainly things that we fallible humans do from time to time. However, when people have experienced those things with respect to TDD, that isn’t what they say. Instead, they say TDD categorically does not help. It is inconceivable that they could have made a mistake. The tool they used must have been at fault. They are here to warn you against being harmed by that tool.
Simulating an ALU in F#
Simulating an ALU in F#
I’m a rank beginner with F#, and I was looking for a fun way to get started. The usual tutorials seemed a little stale. Then it occurred to me that logic gates could be modeled as functions pretty easily. Why not practice F# by writing some functions that mimic the behavior of logic gates?
Continue reading Simulating an ALU in F#
TDD: Let the Tests Drive
As long as we write tests, what’s the big deal about writing them “first” rather than “last?” Let’s explore that question.
The video looks a lot better on YouTube than it does here. Try https://youtu.be/Bf89rd0o5-0.
https://youtu.be/W1-IjCbzKAs
When we’re conscientious about writing examples before production code, and we drive all our production code from executable examples, we can enjoy several benefits:
- Helps us remember details and not overlook things
- Helps us avoid over-engineering or going too far with our design
- Helps us keep the design simple
- Provides a safety net for experimenting with different implementations
- Provides a safety net for refactoring
- Gives us frequent positive feedback so we don’t feel beaten down at the end of the day
- Provides executable low-level documentation of everything the application does
- Makes it easier to locate the source of bugs; keeps us out of the debugger for the most part
- Creates a regression test suite as a side-effect of writing the examples that drive the design
- Equally useful for emergent design and up-front design, and for greenfield development as well as enhancements and bug fixes
Looking at TDD through a lean-agile lens
It’s a commonplace to say there is no “silver bullet,” and everything we do in the software field has to take context into consideration. In fact, this is quite true. TDD is a useful technique to know. To know TDD well, you must understand why and when it is useful, and how to do it correctly. If you apply TDD for the wrong reasons, in the wrong places, or in the wrong way, then it will not yield any value.
Many of the complaints people raise about TDD and about unit testing in general boil down to a misunderstanding or a misapplication of practices. Some complaints, however, are completely valid. You have to make your own professional judgments about such matters. To be equipped to make such judgments, you need to understand how TDD can add value in your work; and when it will not.
Continue reading Looking at TDD through a lean-agile lens
Bringing TDD and automated testing to the mainframe platform
Can contemporary lightweight software development and delivery methods “scale” in large enterprises without appropriate support for the venerable IBM mainframe platform? Thought leaders in the “agile” community seem to think so. For example, this proposed session on code isolation and automated testing for mainframe applications received almost no notice from the review team for the Agile 2015 conference. The two reviewers who noticed the submission seemed not to understand what it was about, or to see any relevance or usefulness in it.
It’s true that some large enterprises don’t have mainframe technology. Apple, Google, Amazon, and a handful of others built their businesses in an era when alternatives to the mainframe were plentiful. Those companies tend to be relatively uninterested in “agile” and “lean” methods, as they have come up with their own ways of doing things, and their financial position doesn’t lead them to believe they need to change. They’re probably right. If they were “dysfunctional” they probably wouldn’t be doing quite so well financially…a minor detail often overlooked by enthusiastic change agents.
However, the majority of larger enterprises have been around for decades. They have used computer technology all those years. The general pattern has been to layer new technologies on top of old rather than to migrate applications. Name a large bank or insurance firm that doesn’t have a significant investment in mainframe systems. Now explain how you would bring agility to those organizations just by setting up a few Scrum teams, applying good technical practices only to the outermost layer of their technology stack, and ignoring technical practices and tooling on the mainframe platform.
Continue reading Bringing TDD and automated testing to the mainframe platform