Category: Uncategorized

Posted on by

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?

Posted on by

Show Me a Study

My friends know me to be skeptical of “studies” about software development techniques. The main reason for my skepticism is that such studies are rarely undertaken by people who have any understanding of what they are studying. They combine data points from different sets of observations as a way to try and accumulate sufficient information to make charts and trend lines, but often the data points aren’t consistent enough for the aggregated data to be meaningful. I wonder whether many studies of programming techniques are based on enough observations to be meaningful, and whether the researchers’ analysis of the results is based on any direct knowledge of the subject at hand.

Continue reading Show Me a Study

Posted on by

Doing Scrum Perfectly

Sometimes I use the phrase, “novice Scrum team,” to describe a team that’s new to Scrum, still settling into the routine of sprints, and still getting a handle on the underlying values of Scrum. Often, these teams are in the process of adopting unfamiliar technical practices like test-driven development and unfamiliar processes like continuous integration, and learning to collaborate across roles that had been sequestered in functional silos before the cross-functional Scrum team was established. They’re learning a lot of new things at the same time.

Quite a few people appear puzzled or bemused by the phrase. It occurs to me they may think of Scrum as a fixed set of rules to follow, rather than as a starting point for ongoing improvement. You either follow the rules or you don’t. There’s no concept of “novice Scrum team” because there’s no concept of ongoing improvement: When you follow the rules of Scrum, you’re doing Scrum. You either do Scrum or you don’t. That’s all there is.

Continue reading Doing Scrum Perfectly

Posted on by

TDD: Let the Tests Drive

As long as we write tests, what’s the big deal about writing them “first” rather than “last?” Let’s explore that question.

The video looks a lot better on YouTube than it does here. Try https://youtu.be/Bf89rd0o5-0.

https://youtu.be/W1-IjCbzKAs

When we’re conscientious about writing examples before production code, and we drive all our production code from executable examples, we can enjoy several benefits:

  1. Helps us remember details and not overlook things
  2. Helps us avoid over-engineering or going too far with our design
  3. Helps us keep the design simple
  4. Provides a safety net for experimenting with different implementations
  5. Provides a safety net for refactoring
  6. Gives us frequent positive feedback so we don’t feel beaten down at the end of the day
  7. Provides executable low-level documentation of everything the application does
  8. Makes it easier to locate the source of bugs; keeps us out of the debugger for the most part
  9. Creates a regression test suite as a side-effect of writing the examples that drive the design
  10. Equally useful for emergent design and up-front design, and for greenfield development as well as enhancements and bug fixes
Posted on by — 2 Comments

Technical Debt: The Man, the Metaphor, the Message

Ward Cunningham, a fish of some note in our small pond, wanted to deliver software incrementally to a client in the financial sector. The client didn’t see the value in doing that as opposed to delivering in a “big bang” fashion. To help relate the idea to the client’s frame of reference, Ward came up with the “technical debt” metaphor. It’s explained pretty well in an Agile Alliance article.

Continue reading Technical Debt: The Man, the Metaphor, the Message

Posted on by

Slack, Flow, and Continuous Improvement

One of the key ways to keep work moving forward is to avoid working on too many things at the same time. Ideally, a person should finish what they’re working on before starting anything else. Similarly, a team should complete the work item or ticket or story (or whatever they call it) they’re working on before picking up the next one. At a larger scale, a software delivery organization should limit the number of projects in flight concurrently, and strive to “stop starting and start finishing,” as David Anderson put it. That’s what portfolio management is for (among other things).

Continue reading Slack, Flow, and Continuous Improvement

Posted on by

Introversion and Agile

The relative effectiveness of collaborative work over individual work for many (not all) activities has become well-enough established by now that hardly anyone questions it. No one establishes an “agile” work space in such a way as to maximize disconnected, individual work and to minimize direct communication. That would be absurd.

And yet, people are determined to defend their comfort zones. A popular way to avoid working collaboratively is to say, “I’m an introvert.” Often, this is stated flatly, with a tone of finality, as if the word “introvert” completely explains why it is impossible for the individual to collaborate with others. Obviously, an introvert has to work alone all the time. They are hard-wired that way. It’s innate. It’s an immutable trait. There are no variations or nuances. End of argument. Now I’m going to turn my back on you and put my headphones back on. Go away.

There are a couple of problems with the way people typically throw the word “introvert” around.

Continue reading Introversion and Agile

Posted on by

Recruiting and interviewing in confusing times

For context: This post is about recruiting and job-seeking in the area of software development, testing, infrastructure engineering, and related disciplines. It isn’t general.

There’s a lot of discussion just now online and offline about endemic problems in the software industry around discrimination, pay discrepancies, hiring practices, humane workplaces, and questionable interviewing methods. Most of that discussion is highly emotionally charged, to such a degree that it’s “unsafe” to disagree with just about any comment online, or even to agree with a comment using words the “owners” (is “dominators” a word?) of the discussion haven’t approved.

That situation does not seem healthy or constructive to me. So, I thought I would take a few minutes to try and cut through some of the emotion to understand what’s wrong with recruiting and hiring in our field, and whether there are some concrete steps people can take, on both sides of the interviewing table, to improve things.

Continue reading Recruiting and interviewing in confusing times