Sunday, June 13, 2021

Friction

In software development, ‘friction’ is any and everything that keeps you from moving swiftly to getting your work ‘fully completed’. It’s worth understanding that the job is not done until it’s out there, being used smoothly by a bunch of people. Coding it is a start. Testing it is better. Releasing it is great, but it’s still not done until it’s been running correctly for long enough that it won’t end up showing up back in the shop needing repairs.

Along the way, there are literally millions of little things that get in your way and slow you down. Things that are unspecified, or awkward, or require you to remember a lot of trivial stuff. The problems can be neglect, or ambiguity, or lack of exposure. It doesn’t matter what it is, or whether other people think that it is normal and acceptable, only that it has resulted in you slowing down a bit.

In some cases, particularly with methodologies and ‘controls’, the friction is actually deliberate. Someone, somewhere, wants you to slow down. Sometimes they have extremely good reasons for this. Sometimes it is just a random accident of the dysfunction in your organization. Most often, there is nothing you can do about the larger systemic friction. You just have to live with it.

But there are lots of smaller, closer to home, areas where you can and should eliminate friction. You should always leave a little bit of extra time, so you can remove one or two small issues a week. If you keep that up over the long haul, things will gradually get a lot better.

If it’s awkward to find the stuff you are looking for, you can invest some time in organizing it, or acquiring better-searching tools, and learning how to use them properly.

If it’s repetitive actions, you can automate them with scripts, or cute little GUI widgets to trigger larger actions.

If it’s volatility coming directly from the domain, you can spend time to learn more about the domain and talk with as many people as possible. In all domains, some issues are intrinsically dynamic. It’s a huge mistake to try and treat these statically.

These things are all in your control. You can spend time improving on them. Even if they are little, they add up quickly.

If the issue is not enough time, you need to learn to add a bit of slack in your estimates. Oddly, if you get ahead of the ball and reduce a lot of friction, you’ll find that you’ve caught up and often have more time than you need. The mistake is getting behind in the game, and then digging the hole deeper and deeper by just trying to ignore all of the little problems around you.

Stop digging, apologize for being late and fix a small issue or two.

No comments:

Post a Comment

Thanks for the Feedback!