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

Posted on by — 5 Comments

Bringing TDD and automated testing to the mainframe platform

Can contemporary lightweight software development and delivery methods “scale” in large enterprises without appropriate support for the venerable IBM mainframe platform? Thought leaders in the “agile” community seem to think so. For example, this proposed session on code isolation and automated testing for mainframe applications received almost no notice from the review team for the Agile 2015 conference. The two reviewers who noticed the submission seemed not to understand what it was about, or to see any relevance or usefulness in it.

It’s true that some large enterprises don’t have mainframe technology. Apple, Google, Amazon, and a handful of others built their businesses in an era when alternatives to the mainframe were plentiful. Those companies tend to be relatively uninterested in “agile” and “lean” methods, as they have come up with their own ways of doing things, and their financial position doesn’t lead them to believe they need to change. They’re probably right. If they were “dysfunctional” they probably wouldn’t be doing quite so well financially…a minor detail often overlooked by enthusiastic change agents.

However, the majority of larger enterprises have been around for decades. They have used computer technology all those years. The general pattern has been to layer new technologies on top of old rather than to migrate applications. Name a large bank or insurance firm that doesn’t have a significant investment in mainframe systems. Now explain how you would bring agility to those organizations just by setting up a few Scrum teams, applying good technical practices only to the outermost layer of their technology stack, and ignoring technical practices and tooling on the mainframe platform.

Continue reading Bringing TDD and automated testing to the mainframe platform

Posted on by

Feature teams and vertical slices in a large corporate IT environment

The idea of a feature team that incrementally delivers vertical slices of application functionality is central to many “agile” software development organizations. A feature team possesses all the skills and resources necessary to deliver a customer-centric software feature end to end. How feasible is this model in a large corporate IT environment?
Continue reading Feature teams and vertical slices in a large corporate IT environment

Posted on by

The accordion game

As a middle manager in a large corporate IT department, you feel as if

  1. you are in the middle of an accordion
  2. and the accordion is being played by a monkey
  3. and the monkey has taken some sort of unknown street drug
  4. and the strange music the monkey is playing makes no sense to you
  5. and your bosses think the monkey is a genius
  6. and your subordinates think it’s all your fault
  7. and you don’t see how it could possibly be your fault
  8. and you’re not even sure what “it” is.

You never know whether your job will survive the next re-org. Furthermore, you’re not even sure that your job adds much value to the organization: In a nutshell, you (a) take direction from above and disseminate it downward, and (b) collect data from below, compile it and report it upward. You don’t know how to run the business from the top. You don’t know how to do the hands-on work at the bottom. You have only a vague idea of what’s going on. You can’t trust any of your peers. What will happen to you if your present position is eliminated?
Continue reading The accordion game

Posted on by — 8 Comments

The mother of all management anti-patterns

My book on software development metrics is in the final stages of editing. The editor made a kind comment about one section of the book. She wrote: “This section is marvelous. I wish all management everywhere would read this and pay attention.” Me, too. This is the section:

(begin excerpt)

This may be the mother of all management anti-patterns. Management science has treated human beings as interchangeable machine parts at least since the time of Frederick Taylor’s “scientific management” in the early 20th century, and possibly much longer than that. Even today, many managers loosely refer to workers as “resources” without realizing the implications of the word.
Continue reading The mother of all management anti-patterns