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 MetaphorAuthor: 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.
Collaboration
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 CollaborationScrum pain in large organizations
Although “agile” has been around a long time, and Scrum even longer, many large organizations are only now undertaking “agile transformation” initiatives. People in those organizations who have not had experiences elsewhere with “agile” or Scrum are on the learning curve. I’ve noticed a handful of challenges that seem to be fairly common in these organizations.
Maybe it will be helpful to mention some of the common points of confusion and try to clarify them. I hope so, anyway.
tl;dr warning
Continue reading Scrum pain in large organizations
Gilded Rose: Read by Refactoring
People who practice refactoring often turn to the Gilded Rose exercise, originally posted by Bobby Johnson and extended and elaborated by Emily Bache. The exercise can be approached in many different ways. I think that makes it especially useful for exploring alternative ways of dealing with existing code bases.
Several years ago, Arlo Belshee came up with an interesting way to address existing code that he calls read by refactoring. I will admit that I haven’t discussed this with him directly, nor have I attended his training on the subject. I’m basing this on my reading of the idea online and experimenting with the approach on my own. So, I might be missing key aspects of the idea. Please feel free to correct me if that’s the case.
Continue reading Gilded Rose: Read by Refactoring
80/20 Skills
People in our field like to cite various maxims or laws. To name a few, there are Conway’s Law, Hyrum’s Law,
Brooks’ Law, the Peter Principle, Hofstadter’s Law, the 90-90 Rule, Parkinson’s Law, Sayre’s Law, Eagleson’s Law, Postel’s Law (a.k.a. the Robustness Principle), Linus’ Law, the Dunning-Kruger Effect, the Principle of Least Astonishment, Hanlon’s Razor and it’s notable parent, Occam’s Razor, and of course the ever-popular Murphy’s Law.
I’d like to consider a couple of maxims today: the Law of Diminishing Returns and the Pareto Principle, or 80/20 Rule, in relation to the idea of multi-skilled team members on a cross-functional team.
Continue reading 80/20 Skills
Remote work backlash
<rant>
The Coronavirus pandemic created a need for companies to shift to remote work very quickly. In virtually every case there was no intent to do that, and no plan to implement the change smoothly. Initially, there was a lot of thrashing. Then people started to get a handle on how to manage the work-from-home situation.
Continue reading Remote work backlash
What happened to the test automation pyramid?
In a February 2020 article on cucumber.io, “Eviscerating the Test Automation Pyramid”, Seb Rose points out some of the issues that ensue when people misunderstand the intent of the test automation pyramid (or triangle) originally proposed by Mike Cohn and interpret the model too literally. He suggests if we remove the various levels and labels that people have added on the inside of the triangle, and think about the shape as such, we’ll come closer to the original intent – many tests of small scope and fewer tests of larger scope.
Continue reading What happened to the test automation pyramid?
Traffic
I came across an interesting video about how to relieve traffic congestion, “How to Fix Traffic Forever”, and it seems to me the key points are equally applicable to software development and delivery. What do you think?
Continue reading Traffic
Design by Contract
Design by Contract is a software design approach that is helpful when we are building solutions from small building blocks that interact with one another through interfaces or APIs. The “contract” is the definition of how an interface or API is meant to be used. There’s a good description on the C2 Wiki, a reasonably good article on Wikipedia, and concise explanations in the Microsoft .NET documentation and on the Java Practices site.
Continue reading Design by Contract
Refactoring the Hard Way, Part 2
This is a continuation of an exercise to learn how difficult it is to add refactoring support to a text editor. There’s no intent to produce a fully-featured and robust solution, but just in case it proves to be useful I want to focus on a couple of tools that don’t already have satisfactory refactoring support for widely-used legacy languages.
To be clear: This isn’t a “lesson”. I’m not teaching you something I already know how to do. I’m writing down what happens as I try to teach myself how to do something that’s new to me. Others already know how to write refactoring logic and how to write extensions and plugins for editors and IDEs. Fair warning, in case that sort of thing doesn’t interest you.
Continue reading Refactoring the Hard Way, Part 2