How to practice isometric software development

Pushing against a wall makes you stronger and does not bother the wall and is stupid

You work at a semi-large company. The type of company that innovated very quickly years ago and operated as a strong offense - constantly growing and increasing customer happiness by shipping features constantly. Sure, things broke all the time, but they also were fixed quickly and the rate of change was so high it grew a healthy business, so healthy that now new people want to bet their money and careers on it.

These new wish to become not wildly prosperous but predictably successful. Before you might grow -15% to 35% year over year, now they want 8-10% consistently.

This means the company starts to focus on defense a bit more, and some things change:

• security and compliance teams appear out of thin air and start sending you emails they really want you to ignore or really want you to read

• complex software development processes and reviews are a part of your daily life

• you notice a new group of highly trained businees types that all got MBAs together (or this job is the final MBA capstone project, there is no way of knowing)

• Lots of post-mortems and wondering how we can become consistent

• Lowering expenses

It feels strange; before you felt like the company was:

Move fast and break things

Now it seems like it is:

Slow down to avoid failure, then blame things

Before you felt like you were up against external realities: competitors, markets, opportunities, real customers making buying decisions.

The new internal realities: people vying for power, existing processes built on scar tissue of previous failure, paranoia, fear, and a culture of mild blame.

Now you need to figure out how to ship software within this environment without getting into trouble.

Isometric Software Development Process

Operating within these constraints is tough, but possible. Isometric exercise is when you strengthen your muscles by pushing on things that do not move. It isn’t great for your flexibility, but it does make you stronger. These internal constraints are the wall, and you need to figure out a way to get stronger without being able to move.

There are a few ways to do this.

Ride the Prevailing Winds

With a large company, there is an infinite list of competing priorities. One of the functions of the leadership team is to pick a theme for a little while to focus on. This might be a vision from the executive team or middle leadership¹ to reduce expenses, or move to the cloud, or integrate existing products, or work on SOC2-Type II compliance, or focus on retaining existing customers. The list is infinite, and sometimes you are told the theme, while at other times you are not, as in when the theme is to lower headcount or focus on blaming Terry more frequently.

If you are operating within this theme, all the rules are softened. Yes, you have to pretend to follow all the existing constraints, but if you mention how your project is meant to directly address this theme (and your project does this, absolutely yes sir) it opens doors. There are less questions asked. Everyone seems to want to be perceived as being supportive of the theme.

An example:

• You have been told to reduce the time it takes to fix bugs.

• You close 50% of all bugs without reading them, and then return to your campaign in Ghost Recon: Wildlands.

• You are called out on this.

• You pull up a graph showing that bug close time has been rapidly improved, and give a little prepared speech about how important this is to the customer, as the stability of the software is key to providing value to them and also retraining them (last quarter’s theme)

• You argue that a good bug report is key to bug close time, and that the 50% of bugs, that you chose at random, did not have enough detail. You are partially right about this; the product manager have been creating sloppy bug reports, because they heard the theme was “bugs” and are fearful of being accused of not focusing on them.

• You then return to your Ghost Recon: Wildlands game (you have almost captured El Sueño), and wait for “better bug reports” to become the theme.

Bulk Approval Operations

If you have a large overhead to getting things approved within a cumbersome process, find a way to make one approval turn into a template approval that allows you to do a dozen things. App developers figured out this trick when trying to get their mobile applications approved by the Apple App Store, back when their responses took 3 weeks and felt like they were made by putting answers in a cow pasture and seeing where the cattle went to the bathroom. You got approval for your app shell, then had it load dynamic content which you were able to ship without having to get another app approval. Sure, the first time took longer, but once it was approved you could move faster.

How can you accomplish this?

• Spend a large amount of timing baking cakes for the approval committee.

• Have your first handful of approvals be for things where failure is impossible.

• Create extensive documentation on how the approvals work, and submit new requests that link to the documentation and your first request which went flawlessly. If anyone asks, this is “round 2” of the prepapproved request, but you are making sure you are “doing it right”

Fat and happy, they will perceive you as an uninteresting person to question and turn their attention to the problem children.

At a technical level, one way to accomplish this is to get approval for a new feature, and ship it with hundreds of dynamic conditional statements (some call them feature flags) which allow you to carefully finish the project by using the same approval and shipping over and over under its approval umbrella.

Carefully Deflect Ownership

Some call it playing “hot potato”, other call it definining clear system boundaries. All we know is that if your team isn’t working on it, because you never clamied it, then it is harder to be blamed for it.

Handle Any Criticism Using Mind Games

Every company has people who will stop you from doing the above moves, or try. You can usually use the existing theme, or current theme if enough time has passed, to do this shut down dissent, but if you can’t there are ways to terminate conversations which are highly effective. Learn them.

Here are some examples:

• Ask if we are following the “letter of the law” or “spirit of the law”.

• Just ask questions, like “Do you think that upper leadership thinks that the five of us having this discussion is a good use of company resources?”

• Reference the inherent tradeoffs of risk management. As in: “what are the real odds that my request for a font weight change on this internal website will cause production outages vs. the chance of me body checking you into the wall at the company party, Terry?”

• There are many other Thought-terminating clichés that can be employed as well.

Make Peace

After any of these mild confrontations, make sure to apologize and bake another cake. You need to make peace with all your coworkers, as well as making peace with exactly where you work now: a defensive, frightended organization run by people who want to hold on to the sucesss that another earlier stronger organization built.

1. Sorry, middle management. Middle leadership feels like the wrong phrasing. Hmmmm.