What is fast anyway?

Finding ways to move fast without it becoming the goal.

I’ve been internally wrestling with the concept of what fast means in software, and came across this little gem about Speed Is the Consequence. Not the Goal.

Software is an interesting subject because while it is built on hard sciences such as mathematics, it’s soft and malleable like thoughts. Software isn’t concrete like a building or a road, it’s something purely mental held together by 1’s and 0’s. Something in the physical world is done once it’s built, but software isn’t like that.

I’ve heard terms like we need to move faster or we aren’t shipping code fast enough. If you don’t hear it, some teams feel it. There’s also a parallelization of how building software is the same thing as Toyota’s factory and how it makes cars.

Sometimes we have to read between the lines and maybe this is what they mean.

1. We need to find ways to provide value to our paying customers if we want them to come back.

2. We don’t have product market fit - start throwing spaghetti at the wall and we’ll do what sticks.

3. Our competitors have an advantage and we are losing market share.

4. Go make me more money!

5. We need to stop deploying production code from our laptops.

If you’re in the boat of the poor souls who have to deploy code from their laptops, there is room for improvement, but I’m not talking about that.

I believe in moving fast with small incremental improvements whether it is technical or organizational. This was popularized in the book “Atomic Habits” by James Clear, and further shown to work by the British Cycling Team referenced in Chapter One.

The more I think about it, the more I believe that to move fast most of the changes of a mature company need to happen at an organizational level, not a technical level. Here are the two that first come to mind.

1. Organizational Structure might need to change.
   ”Conway's law describes the link between the communication structure of organizations and the systems they design. It is named after the computer programmer Melvin Conway, who introduced the idea in 1967.” If your software
   is hard to read, feels like siloed black boxes, and you keep thinking that the code you are reading is unnecessarily complex. It could be how the organization communicates and a reorg is necessary.

2. Makers are on Manager’s time.

   There are Makers and Managers and the way their day is built is completely different. The Manager's schedule is usually blocked out in thirty to sixty-minute increments and each context is similar. The maker schedule needs large blocks of time to solve complex problems. When writing code, even loading context can take up to 30 minutes.

While we might tend to want a tool, framework, or language to solve our tech problems, I wouldn’t start there. As teams and companies look to optimize their work, they should find places to make room for more organizational changes that reflect the desired reality.

Additional Reading

https://qeunit.com/blog/speed-is-the-consequence-not-the-goal/

https://www.satisfice.com/blog/archives/856

https://paulgraham.com/makersschedule.html

https://en.wikipedia.org/wiki/Metacognition