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
Terminal Velocity for Agile Teams
The most popular metric for agile software development teams, by quite a margin, seems to be velocity. Yet, experienced agilists don’t find velocity particularly useful. Even some of the authors of the Agile Manifesto who played a part in defining velocity, as well as story points and planning poker, have moved on. But today, as large organizations undertake major initiatives to “transform” into agile organizations, there is a strong emphasis on velocity as a key metric.
Despite the advice of leading agile consultants and coaches, and books like Doc Norton’s Escape Velocity and my own Software Development Metrics, corporate leaders stress the importance of velocity in their transformation programs, and require their software development teams to track and report it.
Continue reading Terminal Velocity for Agile Teams
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.
Cultural Divide and Implications for Tools and Practices: Mainframe vs. Distributed
I began my career working on IBM mainframes in 1977, moved away from that platform gradually from about 1987 to about 1994, and have recently begun to return “home” again (also gradually). I have been heavily influenced by some of the advancements in software development in the world of Java, C#, and similar languages.
As I work more closely with mainframers and with vendors and open source developers who focus on the IBM mainframe platform, I’m confronted with cultural differences between those who work on mainframes and those who work, as mainframers put it, in the “distributed” world (that is, everything that isn’t a mainframe).
Continue reading Cultural Divide and Implications for Tools and Practices: Mainframe vs. Distributed
In an Ideal World
Warning: Rant.
Many of us who try to help organizations and teams improve the way they carry out software development and delivery work encounter a bizarre response from clients on occasion: “Your suggestion may work in an ideal world, but it can’t work in the real world.”
Why bizarre? Because they are experiencing challenges in their work and they have engaged outside helpers to advise them, and yet they dismiss the helpers’ advice out of hand. If all they intend to do is continue working in the same way as before, and claim that nothing will work “in the real world,” why do they bother to spend time and money to engage outside help?
Many people assume the advice we offer was just made up on the spot, or represents some academic theory that hasn’t been tried in the field, or requires the organization to be perfect even before they can try to implement the advice. In reality, the things we suggest are not new.
Notation and Thought in Unit Testing
The paper “Notation as a Tool of Thought” by Kenneth E. Iverson of the IBM Thomas J. Watson Research Center was published in the Communications of the ACM, Volume 23, Number 8, 1980-08. It’s available online at https://www.jsoftware.com/papers/tot.htm. Thanks to John Arundel (https://twitter.com/bitfield) who called attention to the paper in a tweet.
The paper deals with the way an appropriate notation influences people’s thinking in a given domain. Iverson was interested in the domain of mathematical computing, and he uses the APL language to illustrate his ideas. APL is an array-processing language Iverson developed in the 1960s. It has a following even today. You can read more about it on the APL Wiki at https://www.aplwiki.com/. You can try it out online here: https://tryapl.org/,
In this piece, I’m going to stretch the point a bit and apply some of the principles of notation Iverson presents in his article to a different domain: unit testing of application software.
Continue reading Notation and Thought in Unit Testing
Microtests and Unit Tests for z/OS Applictions
The idea of “unit testing” is pretty well-known in programming circles. Everyone has some concept of what it means and most software developers practice some form of unit testing.
Yet, there is disagreement about unit testing. If you’re trying to get a handle on this topic for purposes of supporting existing applications in a z/OS environment, you may find a lot of contradictory information online. Opinions are often presented as facts, and are defended strongly. I’d like to try to tease some of that apart so you can make practical sense of it.
Continue reading Microtests and Unit Tests for z/OS Applictions
Cobol Rising
As early as the mid-1980s, people were quite certain Cobol was on its way out. Most of us looked for opportunities to learn emerging technologies and shifted our career focus away from Cobol and from its primary platform, IBM mainframes.
At that time, opportunities opened up for those who understood the old technology and could help re-implement solutions in the new. It was a way for us to learn other technologies and build a new career path.
There was pressure to replace older applications based on Cobol, as the mainframe was due to die at any moment.
Cobol forgot to die
But a funny thing happened on the way to the cemetery. Writing in Forbes in July, 2020, Tom Taulli notes:
- “[Cobol] powers about 80% of in-person financial services transactions and 95% of ATM swipes.
- On a daily basis, it processes $3 trillion in commerce.
- There are over 220 billion lines of code and 1.5 billion are written each year.”
The Problem with Metaphor
Some time ago I wrote about the use of metaphors in the field of software development (Metaphorically Speaking), and more recently on the risks of using colloquial English with international colleagues who learned business English (English for English Speakers). I’d like to revisit the subject, as I still see a lot of confusion out in the world, and we’re still coining new terms that strike people differently than intended.
Continue reading The Problem with MetaphorCollaboration
Contemporary software development methods emphasize collaborative work over solo work. I remember this idea gaining momentum from as far back as the 1990s, when Extreme Programming was becoming known, including one of its core practices, Pair Programming.
In retrospect, I can recall many instances when people collaborated in an ad hoc way to solve specific problems, going back to the beginning of my IT career in 1977. I’ve read articles and heard stories about the value of collaborative work in engineering going back at least to the 1950s. There was even a deliberate experiment in 1975, carried out by the US Army, on the value of “two-person teams” in software development (the article does not appear to be online anymore, but there is an excerpt in this old blog post: Does pair programming work?).
In all these cases, from formal studies to informal “war stories” told over coffee or beer, direct collaboration provided immediate and palpable benefits to the people involved. That has been my experience, as well. And yet, it seems as if solo work continues to be the norm.
Continue reading Collaboration