What developers say: "I'm almost done."

What it really means: A small thread.

#noestimates
#itsdonewhenitsdone

"I don't know when I'll be done. Much of my work is intrinsically unpredictable and unknowable in advance, and that you're interrupting me to ask is making me even slower, so here's a sweet convenient lie to make you go away happily so I can get back to focus on my job."

"And when you dare ask that damned question again, I'll give you a half-baked half-assed solution that'll make all future work slower."

That is no excuse for utter unpredictability.
But the justified business demand for predictability does not justify either to demand for predictability and pretend there can be predictability where in fact there cannot be such thing.

(Of course, this ain't binary.)

This is intrinsically related to queueing theory. Do not utilize your team to 100%. https://twitter.com/christianhujer/status/1390653758950940672?s=20

Leave room for slack. Slack is required for all kinds of stuff:
• Experimentation
• Exploration
• Ideation
• Spontaneous improvement (maintainability, automation, optimization)
• Unplanned work
• Dealing with user feedback

Loading a team to 100% is a surefire way to slow it down in all kinds of ways. For example, no slack for spontaneous improvement is a breeding ground for design smells.

The 5 design smells are:
• Rigidity: High effort for change
• Fragility: High risk of change
• Inseparability: High effort of reuse
• Opacity: Difficulty to understand code
• Viscosity: Slow, wasteful processes

Coupling is the primary culprit of design smells. Coupling is a dependency that propagates change. This is important. Not all dependencies are bad. Dependencies are bad if change impacts us negatively. That leads us back to the 5 design smells.

Rigidity: If I want to make a change in one place, and in order to do that, I have to make changes in other places, too, it means that there is a dependency between these places that propagates change - coupling.

Fragility: If we make a change in one place, we have no good means to predict the impact on other places, compromising existing behavior in those other places. There is a dependency that propagates change - coupling.

Inseparability: We've developed user management for that forum, and now we can't reuse it for the online shop although the requirements look the same. Why? Because the user management is entangled with the rest of the system. It is coupled.

Opacity: I can't understand this piece of code by only looking at it. In order to understand this piece of code I have to look in many other places as well. This piece of code fails to communicate intent, because of (in this case) coupling.

Viscosity: Making changes is slow because when I change this I also have to rebuild that, and that thing over there as well, and then I have to re-test all of this, so just building and verification takes ages, because of (in this case) coupling.

These design smells should be fixed (by refactoring) the moment we discover them, more precisely, in the last responsible moment, which is the moment right before they would impact us negatively. But for doing so, we need sufficient slack.

With every bit of time that passes between the painful discovery of a design smell and the fix, a number of things happen:
• Pain fades to numbness
• Knowledge fades
• Quality spirals downwards
I'll explain.

When we just discovered a design smell, we usually have a high amount of information of why the design smell impacts us. We experience the "pain" of the design smell, and thus understand its urgency. As time passes, this feeling will subside and we get numb. Motivation decreases.

When we just discovered a design smell, we usually have a high amount of information on how to fix it. If we don't fix it right away but have to plan that for in, say, 4 weeks, a lot of this knowledge will fade, making the fix more expensive. Also, motivation decreases.

When we allow a design smell to live on instead of fixing it before it hits us, we create workarounds that spread like cancer through the code base, sending it another turn downwards on the spiral of quality. Now we have multiple design smells in different places.

The only way to deal with design smells properly is to fix them right and there when they are discovered. That is only possible with sufficient slack.