Year: 2015

Posted on by

Should coaching be treated as hourly contract labor?

Often, companies try to balance staffing with the natural variability in IT workload by engaging contract workers. They don’t want to make a long-term employment commitment to the number of people required to handle their maximum workload. So, they hire enough full-time employees to handle their typical workload, and in periods when the workload is higher they bring in temporary workers on a contract basis. That way, companies can expand and contract staff to match the internal demand for IT services.

Problems occur when the parameters of the temporary staffing engagement are at odds with the nature of the work performed. Because “coaching” has not been a well-understood category of services, it has more-or-less accidentally fallen into the “hourly contract” mode. Is this appropriate? Does this model cause difficulties for any of the three constituencies that have an interest in it: The clients, the workers, and the middlemen?

Continue reading Should coaching be treated as hourly contract labor?

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