Author: neopragma

An IT professional since 1977, I’ve served in a variety of technical and managerial roles. I’ve worked mainly as a consultant since 1984, keeping one foot in the technical camp and one in the management camp. A lifelong learner, I’ve always been interested in exploring better ways to deliver business value through information technology. I’m currently working as an independent consultant, trainer, and coach with an interest in bringing together the best of tried-and-true methods and the best of leading-edge methods to help businesses realize the maximum return on their IT investments and efforts.
Posted on by

Whither Tuckman?

There’s a common model people seem to believe in implicitly, known as the Tuckman model, named for psychologist Bruce Tuckman, who published the idea in 1965. The idea is that all teams go through several distinct stages: Forming, Storming, Norming, and Performing. You can probably guess what those stages are like based on their names. The model has been a mainstay of agile coaches for many years.

But I’ve had doubts about the Tuckman model for a long time. My personal experience has been that once people get used to working in a collaborative way, they can move to new teams without any friction.
Continue reading Whither Tuckman?

Posted on by

Code Freeze 2021: Mob Programming Workshop

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

Posted on by

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

Posted on by

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.

Continue reading Pain today, gain tomorrow?

Posted on by

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

Posted on by

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.

Continue reading In an Ideal World

Posted on by

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

Posted on by

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

Posted on by

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.”

See COBOL Language: Call it a Comeback?.

Continue reading Cobol Rising

Posted on by

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 Metaphor