A lot of people are doing remote Mob Programming sessions now that most of us are working from home. I participated in a few and hosted one in the past week. It’s been a good learning experience. I feel as if we (as an industry or community) are rapidly learning how to make this approach work for regular work, virus or no virus.
Continue reading Remote Mob Programming: Lessons from This Week
Category: Uncategorized
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
It’s time to re-group and prepare for the upturn
In December 2008, I attended a talk by Niel Nickolaisen about his Purpose Alignment Model, or PAM. I found it compelling and useful, and I’ve applied it with many clients since then.
I might describe it crudely as a typical consultant-style “quadrant diagram” showing mission criticality or alignment with business purpose on the X axis, and market differentiation on the Y axis. There’s a walkthrough of a hypothetical bank business in my book, Technical Coaching for IT Organizational Transformation, and similar descriptions on Todd Little’s blog, on Cory Foy’s blog, on KBP Media’s site, and many other sources you can find easily online. Some people call it the Purpose-Based Alignment Model, instead of Purpose Alignment Model; bear in mind those names refer to the same model, which was originally called the Purpose Alignment Model or the Silly Little Model, after co-creator Todd Little.
One of the ways the model can be used is to think about how to position or re-position a company during economic downturns. Companies that use downturns to prepare for the next upturn are positioned to hit the ground running when the economy ramps back up again, as it always does. Companies that react to downturns in fear, by cancelling initiatives and halting capital spending, tend to lag behind the competition when the economy emerges from the tunnel. Their behavior during downturns is a telltale that they can only prosper by following those with better leadership, feeding on the excess the successful companies produce during the good times.
In the talk, Niel had just finished saying more-or-less the same thing when a participant in the session asked him what his company was doing just then. (You may remember Q4 2008 was the start of the “financial crisis” of the early 2000s.) He replied that they were cancelling all initiatives and halting capital spending. They intended to wait and see what other companies did, as a signal to know when it would become safe to operate normally again. I was surprised at the answer.
In the year 2020, we’re in another economic downturn. Most companies are handling the situation by cancelling all initiatives and halting capital spending.
Now is the time to prepare to hit the ground running when the economy emerges from this tunnel. The companies that will succeed when the economy rebounds are already investing in building the capabilities and skills of their staff (through training and mentoring), and preparing their work environments for the post-pandemic world – physical office setups that minimize the risk of infection (changing open-plan work spaces, reducing the use of conference rooms), adjustments to work schedules to avoid forcing people to crowd together unnecessarily (such as waiting 30 minutes at a bank of elevators to go to their floor in the building, because employees must all arrive at the same time), changing some common operating procedures (such as requiring employees to crowd together to listen to executive announcements or “town hall” meetings, when they could listen just as well over the computer network), and intentional support for remote or distributed work.
Consider investing in training for your staff. Take advantage of the free training offers that have proliferated, as training companies struggle to remain visible in this slow market. But don’t expect training to remain “free” forever. There is value in good training, and value doesn’t fall from the sky like rain…at least, not usually. Even in these times, the highest-quality and most practical training for technical staff isn’t offered free of charge, with good reason. You get what you pay for.
Effective Distributed Collaborative Work
Everyone’s talking about remote or distributed work these days. Here’s another opinion, for what it’s worth.
Steve Glaveski describes Matt Mullenweg’s concept of five levels of distributed work in a March 29 article on Medium. You can read it for yourself. In fact, you should do so, as I’m not going to summarize it. The rest of this article assumes you’re familiar with it.
Just now I’d like to make an observation about Level 4, Asynchronous Communication, and the implications for software development teams in particular.
On the path from dealing with distributed work in an ad hoc way (Level 1, Non-Deliberate Action) toward the goal state (Level 5, Nirvana), “where your distributed team works better than any in-person team ever could,” the ability for individuals to work effectively without constantly interrupting each other is consistently equated with “better.” As people build skills in doing this, and the organizational culture adapts to it, performance improves.
That’s probably true for many kinds of office work, but not for all kinds.
Continue reading Effective Distributed Collaborative Work
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.
Reducing process overhead in Scrum
In a social media discussion in mid-2019, several people expressed surprise at the idea that Scrum might include “overhead.” The confusion seemed genuine. Some people asked for examples. It seemed they were unable to conceive of “overhead” in Scrum.
The popularity of Scrum has led to an interesting situation in the Agile community. Many people view Scrum as The Answer. It’s the only and best way. There is no possibility to improve beyond Scrum. Everything in Scrum is valuable by definition.
In reality, every process includes overhead. We do things for customers/users, and we also do things to position ourselves to do things for customers/users. When we don’t distinguish between the two, we can fall into the trap of trying to perfect our overhead activities, rather than minimize them.
English for English speakers
In Howard Myers’ 1972 short story, “Out, Wit!” physicist Jonathan Willis discovers the secret of alchemy, and publishes a paper describing how to make gold. Unfortunately for him, he writes the paper in an ironic style that leads people not to take it seriously. Making things worse, his work contradicts the prevailing wisdom in the scientific community, and senior researchers shut him down.
No one takes Willis’ paper seriously…except the Russians. They understand English well enough to comprehend the content of the paper, but not well enough to understand the humor in it. They return to the USSR, where they apply the techniques described in the paper to produce large quantities of gold, which they use to collapse the capitalistic economies of their enemies.
The common language of work
In the global economy of the 21st century, English has become the de facto common language for international scientific and academic exchange, business, and technical work. It’s the official corporate language in many international companies. It’s the practical working language for software teams that include members from different countries.
The situation sounds like an automatic “win” for native English speakers. We already know the global language of business. We don’t have to overcome that barrier to be effective in international work – conferences, user group meetings, training classes, working in multinational companies – all doors are open for us.
But…Jonathan Willis.
What’s the cost of interrupting developers?
There’s been some online chatter recently about an old topic – the need for uninterrupted focused work time when doing software development. Some of the comments have surprised me, in part because I thought it was a settled topic. That was silly of me, because of course there are no settled topics.
But it surprised me, as well, because some of the comments suggested a fundamental misunderstanding of how creative work is done: Some people treat creative work the same as repetitive tasks, such as sweeping the floor or washing the dishes, in that they assume creative work can be interrupted over and over again without any cost.
Continue reading What’s the cost of interrupting developers?
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#