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.
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.
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.
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.
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.
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.
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?