Category: Uncategorized

Posted on by — 2 Comments

Billy Pilgrim and the software estimation debate

Warnings:

  • tl;dr
  • sarcasm
  • calories from fat: (don’t ask)

I’d like to begin with an insightful quote. Until I find one, here’s a quote from Vonnegut:

“I am a Tralfamadorian, seeing all time as you might see a stretch of the Rocky Mountains. All time is all time. It does not change. It does not lend itself to warnings or explanations. It simply is.”
— Billy Pilgrim in Slaughterhouse Five, Chapter 4 (Kurt Vonnegut)

The online debate about software estimation may well be the greatest waste of pixels since the invention of porn. Like porn, the debate comprises a never-ending repetition of the same scene over and over again, the very definition of “boring.” And the actors conclude each day in the same state they were in when they awoke. Every day the same, every day exhausting, every day pointless.

The argument, like Kenny of Southpark, refuses to die. It wakes up each morning as if nothing has happened. In a sense, I guess, nothing has.

Anyway, here’s the thing: Despite people’s best efforts and their protestations to the contrary, no one can predict the future accurately and precisely.

Continue reading Billy Pilgrim and the software estimation debate

Posted on by — 6 Comments

The what, the how, professionalism, and pragmatism

Warning: Rant
Warning: tl;dr

So, there’s this idea floating around of technical debt. There are some nuanced definitions, but in general it means bad design baked into the code. The “nuance” has to do with why bad design is baked into the code. There are a lot of debates about this, and you might wonder why, as it isn’t intuitively obvious how anyone could argue in favor of baking bad design into their code.

Yet, they do.

Continue reading The what, the how, professionalism, and pragmatism

Posted on by

The Agile Katamari: Sticking things together and pulling things apart

Different people have different ideas about the current status of the “agile” movement in software development. Different people have different ideas about what “agile” even means. Having been involved with “agile” development since 2002, I’ve had the opportunity to observe an interesting trend: We’ve been gluing a lot of things onto “agile.” Now it may be time to pry some of those things off and get back to basics.

Continue reading The Agile Katamari: Sticking things together and pulling things apart

Posted on by

An opportunistic coaching moment

At one of those massively-wasteful, multi-day SAFe Inspect and Adapt events, held at an offsite conference center, a couple hundred people were jammed closely together in a line for the lunch buffet. There was plenty of food, but the procedure to get it was very cumbersome and lengthy.

A senior IT manager at my client happened to be quite near me in line. He remarked, “This is crazy!”

I replied, “If they ran this place like an IT shop, they would solve this problem by hiring more cooks.”

“But…but that isn’t the problem,” he said quizzically.

“Exactly!” I said.

He didn’t laugh, but others did.

Posted on by

NTFS read/write support on Mac OSX

I find it convenient to share files between systems using an external hard drive, including Windows, OSX, and Linux. The challenge is that different operating systems use different filesystems by default. I’ve been using Microsoft’s NTFS as a common denominator. On Linux, package ntfs-3g supports NTFS, and on OSX the procedure described in this article worked fine until recently. One fine day last week after a system software update, my Air lost the ability to write to NTFS. The old procedure to enable write support for NTFS no longer worked.

Apple seems determined to prevent people from having a simple, seamless way to share files with non-Apple systems other than an online service like Dropbox. So, people have to keep coming up with solutions. Here’s how I regained access to my cross-system hard drive this weekend.

Continue reading NTFS read/write support on Mac OSX

Posted on by

Team practices, code reviews, and lead time

Recently, I watched a webinar that demonstrates a work flow for asynchronous code reviews using a tool from JetBrains called Upsource. The webinar started me thinking about the constraints that might cause a team to resort to asynchronous code reviews in the first place. While the product appears to be well made and easy to use, I wonder whether it offers a workaround to deeper problems that teams might wish to consider solving outright.
Continue reading Team practices, code reviews, and lead time

Posted on by

Accuracy, performance, and maintainability of software systems

Premise: The relative importance of three key qualities of software systems – accuracy, performance, and maintainability – depends on context.

Problem: Many (most?) software developers have a rigid opinion regarding the relative importance of certain characteristics of software systems. Some will insist that performance is always a priority, and that all types of software must execute as fast as is technically possible. Others will insist a system must always produce accurate results, and there is never a margin for error. Others will demand that any software system be designed with maintainability in mind, regardless of context.

Solution: Understand the factors in a system’s operational context that influence the relative importance of accuracy, performance, and maintainability. Apply this understanding when making design choices.

To illustrate how context influences the relative importance of these qualities of a system, here are a few archetypical or actual examples of different contexts in which software is used.
Continue reading Accuracy, performance, and maintainability of software systems

Posted on by — 5 Comments

Every agile scaling framework in the world

More and more frameworks for scaling “agile” software delivery have been appearing in recent years. The proponents of each are adamant that their framework is superior to the others. Yet, customers have difficulty understanding the differences.

This is because all such frameworks are based on the same general ideas, broadly speaking. Proponents insist there are deep differences because they are all competing for the same customers.

Here is a generalized version of conversations that might occur between a salesperson and a prospect looking for help with scaling “agile” delivery.
Continue reading Every agile scaling framework in the world

Posted on by

Using programming problems to screen technical candidates

For some reason, the majority of technical interviews consist only of talking. Sometimes there’s a written quiz of some sort. Rarely, there’s a programming challenge; typically the candidate is free to complete the challenge on their own, in any amount of time whatsoever, in any manner whatsoever, with no opportunity for the interviewer to observe the candidate’s thought process or methods.

And yet, there’s general agreement that professional software development is a team sport involving collaboration skills as well as technical knowledge, and that software isn’t written once and discarded, but rather must be “habitable” for many years into the future. Weak screening methods don’t separate people who can handle that kind of work from those who can’t.
Continue reading Using programming problems to screen technical candidates

Posted on by — 1 Comment

Impedance and Software Delivery

Impedance is a term borrowed from the hard sciences and applied in a loose fashion to other domains. When we use terms in this way, like inertia, momentum, or velocity, they can provide a useful analogy or metaphor for an aspect of social sciences or other disciplines (possibly including software delivery) that helps explain a concept or principle. The problem is that people take these terms too far when they are used outside their intended context. Analogies and metaphors are useful only up to a point.

Continue reading Impedance and Software Delivery