There’s No Perfect Size for a Feedback Loop

The more I drafted this post, the more it felt like I should be writing some type of TL;DR for certain people who read this. So, in an effort to save time, here it is:

I’m writing this for those who are new to self-employment, project management, or generally have less experience than those who are asking “Why are you writing this?” Ultimately, it’s something that most of us learn at some point in this industry, but if we can help one another short cut it sooner rather than later, we all benefit.

If you’re still interested after reading the note above, then I assume you’re looking to get better at this aspect of communication. Which is good, because so am I 😏, and using a small feedback loop is one way in which I’ve found to do that.

Every industry has a bit of their own jargon and many of us laugh about it, yet we all continue to use it when in a professional setting. We’re funny that way.

Anyway, in our industry, one of the phrases that we use a lot – myself included – is “feedback loop.” The first time I ever came across the phrase was with regard to feedback from amplifiers. It had nothing to do with software. Nonetheless, in what we do we generally use it to refer to it as:

• sending a request, comment, or general piece of information to a customer,
• receiving a response from the customer regarding said information.

And for those who aren’t used to the idea (because there are those who do “big bang releases” which I’ll talk about in a minute), feedback loops are usually considered to be small or large.

The longer I’ve worked in software, the more I always aim for A small feedback loop no matter what.

The Perfect Feedback Loop

A small feedback loop means that there’s frequent communication between a business and the customer (so, naturally, a large feedback loop is when there’s less frequent communication).

If you’re gonna use jargon, at least think of it in some sorta fun way, right?

But you know that whole jargon thing I mentioned at the start of the article? In normal conversion, I’d just say:

When it comes to working on a project, I prefer more frequent communication.

And the reason I prefer this and even default to this is because when it comes to building a solution, regardless of size, for someone else, there are always moving parts to consider.

When there are multiple parts to a project, there are multiple points of places where something might need tweaking or change (or that can impact the overall system) and getting it right early rather than later saves a lot of time (and thus money) and stress for most parties involved.

So What?

Why bother writing about this, though? For me, the reason is because the longer I run a small shop, the more I hear from customers about the problems that come with lack of clarity, communication, and project management in prior projects.

Bummer. I don’t want to run that type of operation. So it’s an easy thing to fix, right?

Furthermore, the development industry is filled with people who will take the requirements of a project, assume they understand all that’s needed and then come back only to have built something that not only misses the target but only looks somewhat like that the customer intended.

This isn’t necessarily a knock on programmers, but that whole “[missing] the target” can be fixed if we’d simply communicate with those we’re working with a little more frequently than not.

Don’t assume you know what they want.

Instead, ask questions, clarify the requirement, work on the feature, then present to the customer on a staging environment. They’ll know if you’ve built what they’ve asked. If so, then on to the next feature. If not, there’s more work to do. Operating this way streamlines so much of the points of tension that arise in projects.

And yes, asking a lot of questions can become tedious and even annoying. Big deal. Mention from the outset that you’re going to ask a lot of questions to fully understand the problem before trying to solve it. Give a reason for why you’re doing what you’re doing. It tends to pay off well.

Big Bang Releases

Earlier in the post, I mention “big bang releases” and this generally refers to the idea of a customer providing you with requirements, you going back to work on it for weeks at a time, then showing back up and saying “Hey, I’m done – take a look!” only to find out that it’s way off.

If I were to contextualize this within a type of feedback loop, I’d say there’s not one. It’s not even a large one because no feedback was solicited. It’s simply:

• Here are the requirements for the project,
• I’m done with the project.

Often times, this leads to developers misunderstanding requirements, customers being in the dark about progress, and the overall project going south. Simply put, don’t do it this way.

The Perfect Size?

I don’t know what the perfect size of a feedback loop is. There are some customers I’ve worked with where there are daily check-ins, there are somewhere there are weekly check-ins, and there are some who have said “just complete this and let me know when you’re done.”

Weekly check-ins, commits, releases, etc. tend to be my favorite but that’s because of the size of the project and the size of the team with which I work. Daily isn’t bad either depending on the task.

I never do the big bang style even if a customer says it’s okay. I still like to have checkpoints for my own sanity. So whatever type of feedback loop works best for you, your team, and your customer is going to be the perfect size.