Category: software development

Posted on by

Mastering the keyboard

You’ve probably heard advice from certain quarters that a software developer doesn’t need a pointing device. Everything they need to do can be done with the keyboard, and the work is much faster that way.

The advice seems succinct until you unpack some of the underlying assumptions. Besides that, I think we should think about the effect on novice developers when highly-experienced trainers and coaches tell them to throw away their mouse. They often end up spouting off on their blogs about how anyone who ever reaches for a mouse for any reason is unprofessional.

They have been told by mentors they respect that they don’t need a mouse. All they need is a keyboard. And they’ve practiced working that way through code katas and other exercises. They can navigate their favorite text editor flawlessly using the keyboard alone.

Continue reading Mastering the keyboard
Posted on by

Focus on Delivery

Year by year, the general quality of software worldwide, in every industry, declines. Software testing specialists lament the low quality of applications they use in their regular lives as well as those they are engaged to test.

It has become a sort of game to take photos of crashed billboards, kiosks, train and bus signage, and other software failures and post them online. The examples are called Kevlin Henneys, after a software engineer who started posting such photos several years ago. They’re amusing, but also lead one to wonder why software failures are so common, and how we came to accept bad software as normal.

I don’t claim to know all the causes of the phenomenon. One cause may be the sheer number of people involved with developing software. It’s been said that the number of programmers in the world has doubled every five years since about 1970. That may or may not be absolutely accurate, but in any case the key observation is that half the people writing the software products we depend on in our lives have less than five years experience.

Many of them never learn software development as an engineering discipline. They are graduates of rapid learning programs such as “bootcamps,” aimed at enabling a person to generate a mostly-boilerplate mobile app or web app quickly. Intuitively, this looks like it could be one cause of poor software quality.

But I’m exploring another possible cause in this post: The obsessive, almost manic preoccupation with delivery.

Continue reading Focus on Delivery
Posted on by

Institutionalized Workarounds

I’ve heard it said that sometimes we learn a different way of looking at things, and it influences the way we see the world from that point forward.

For me, one such way of looking at things is Lean Thinking. I became aware of that school of thought about fifteen years ago, and it had a profound effect on the way I approached my work in software consulting and team coaching.

As I learned more about Lean, it became the default lens through which I viewed software development and support processes. It changed the way I think about two concepts that people talk about a lot: value and waste.

My observation is there are two kinds of value and most people don’t distinguish them. Similarly, there are two kinds of waste and most people don’t distinguish them. One of the kinds of value overlaps with one of the kinds of waste. As a result, in many organizations people emphasize the wrong kind of value, while simultaneously treating some forms of waste as “value.”

Continue reading Institutionalized Workarounds
Posted on by

Of Cockroaches and Kings

A recent toot on Mastodon reminded me of a phenomenon I believe is pretty common these days: An unusual event causes us to reconsider our habits and assumptions in some way.

The toot was this one from Benji Weber, posted on February 9, 2023:

The blog post he references is here: I Was Saved By Test Driven Development.

The toot and blog post explain what happened clearly enough; there’s no need to reiterate the details.

The angle I’d like to bring out is the pattern: We operate in domain X in a certain way based on our established habits and our assumptions about the best way to do X. Then something unexpected and/or unusual happens that causes our habitual way of doing X to be uncomfortable, clumsy, expensive, or unworkable. At that point we reconsider our habits and assumptions, and possibly change the way we do X.

Continue reading Of Cockroaches and Kings

Posted on by

The THX 1138 Rule

In the 1971 movie THX 1138, George Lucas’ first feature film, the title character gets in trouble with the law when he gets his girlfriend, LUH 3417, pregnant. In the highly regimented society in which they live, relationships like theirs are illegal. The authorities throw him in jail and redesignate LUH 3417 so he can’t find her again.

THX 1138, along with a couple of other escapees from jail, look for a way out of the subterranean complex where their society lives. Ultimately, THX 1138 is the last of the escapees still at large. The robot cops try to convince him to return with them, but he refuses. When the pursuit exceeds 6% of the budget allocation for chasing escapees, they let him go and he reaches the surface.

The question you may be asking is, “What does that have to do with anything?”

Continue reading The THX 1138 Rule

Posted on by

Key Skills for Software Development

If you understand how these things relate to software development work, then you require no training or coaching.

Self-discipline

Handling stress and working with others requires self-awareness and emotional control. All the skills listed here also require self-awareness and emotional control.

Learning How to Learn

It is widely agreed that software development teams are either improving mindfully, or they are deteriorating in their effectiveness. There is no steady state. To make improvement possible, team members must be open to learning new things and willing to question things they already know.

Focus

To achieve anything, you must focus on it. That means uninterrupted time to think and work. It means finishing one thing before starting another. It means not getting distracted. It means keeping your eyes on the goal and not on dwelling on the difficulties.

Persistence

Overcoming challenges and meeting objectives requires persistence. Embracing change to improve our work requires persistence.

Collaboration

In almost all cases, software development work benefits from collaboration between two or more people. “The more you share, the more your bowl will be plentiful.” – James S.A. Corey, The Expanse.

Trust

Effective collaboration requires trust and the courage to be seen as vulnerable or imperfect.

Leadership

Leadership doesn’t mean giving orders. It means giving credit, giving time, giving space, giving encouragement, giving opportunity, giving trust. The more you give, the more you get.

Rhythm

A steady, predictable, consistent, and sustainable pace of work helps ensure continuous flow, maximize delivery effectiveness, and minimize team stress.

Technical Skills

The field of software is constantly changing. Software architecture, design patterns, programming paradigms, methods and schools of testing, of analysis, and other areas, design principles, development practices, automation, operations, and everything else is a moving target. To get started in this field, you need basic education/training in analysis, programming, and testing, and the non-technical skills listed above so that you will have the ability to keep yourself current with technical advances and to collaborate with and learn from your colleagues.

Without the basic training, you will have no foundation to build on. It would be like trying to run a foot race on top of loose ice floes on water. The general discussion of what skills are necessary tends to emphasize the non-technical side of things; don’t take that to mean there are short-cuts on the technical side. The reason for the emphasis is that the non-technical skills have been underappreciated in the past. On the other hand, don’t worry if you feel as if there’s too much to learn. Once you have the basics, you can build on that knowledge little by little.

Posted on by

En casa del herrero, cuchillo de madera

I was reminded of that old saying when I was struggling to use one of the internal software tools we’re required to use at my current client. In this case, it was one of several time-tracking systems.

It led me to think about the difference in quality between the software the client creates to support customers, and the software they create for internal use. It seems to be a consistent pattern at many companies. They pay a great deal of attention to quality for customer-facing information systems, but when it comes to systems for internal use, they just throw something together quickly, and often carelessly.

The old saying, “In the blacksmith’s house, a wooden knife,” applies to our line of work. The question then becomes, Why?

Continue reading En casa del herrero, cuchillo de madera

Posted on by

Product-Aligned Software Teams

Product-Aligned Software Teams

For a long time now, and starting in earnest in the early 1990s, people involved with software development and delivery have been shifting various aspects of the work to the “left,” if you visualize a software delivery pipeline that runs from left to right. What’s the endgame?

Continue reading Product-Aligned Software Teams

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?