The longer I do software engineering (and even things outside of it), the more confidence I have that one of the most important metrics (most important one?) in any sort of creative process is iteration time.
What do I mean by iteration time? The time between having an idea for change and getting real feedback from the real world what are the results of implementing this idea.
The world is an infinitely complex place. It's very very hard to predict the real results of any action. Because of that, to navigate world it's best to make small steps and collect feedback. The faster you can make these steps, the faster you use a new knowledge, to make new, better steps, which compounds very quickly.
It's a principle so powerful, that taken to extreme allows agents that literally have no understanding of anything, beat everyone.
Examples of things that generally are improving iteration time:
Examples of things that generally are degrading iteration time:
- Design by committee
- Synchronous communication channels
- Centralized control systems
When judging software development processes, projects and teams, it's very valuable to honestly answer the following question: how long will it take from an idea born in the coffee room (a bug fix, feature, or an improvement) to get to the point where we have feedback on how well it's doing in the actual production. No shortcuts though! No cowboy deployments and risking a catastrophe.
Why isn't it shorter? An order of magnitude shorter, maybe? Does it require multiple sign-offs from different people? Are you waiting half a day for a change review? Do you get merge conflicts? Flaky test suite? Can developers quickly test locally, or are they waiting hours for automatic build suite to finish? Can you deploy a change to 0.01% of your users, to quickly gain feedback without risking a bigger impact in case of problems? Is necessary infrastructure readily available? How many forms, tickets, wiki pages, emails, and message do you need before you can test the idea? Can you even tell if the idea worked? Do you have all the metrics necessary and/or infrastructure to compare with A/B testing?
Iteration time can be measured on many levels
You code editor giving you visible feedback, your compiler telling you where is the error, your test suite finding a regression, your peer answering on a Slack channel. All of these have an iteration time and are worth thinking about from time time. Many smaller iterations build into the big one that I'm talking about.
Iteration time is not only the compilation/deployment time and can be non-obvious
Iteration time needs to be measured from the time of having an idea, to getting feedback on that idea. Imagine being able to deploy code change in seconds, but every time getting a compilation error, or hitting a subtle bug in a related code, or figuring out that the code change will require some more work to implement the original idea due to some unforeseen problems. Each of these deployments is actually part of the same iteration.
That's why things like test suites, static type systems, code analysis typically improve the iteration time despite introducing some slowdown on the surface.
It's not always obvious what will increase your iteration time, and what will slow it down. A good example would be pair programming: seemingly tying two developers to work on the same problem, and thus "wasting time", can (will!) actually improve the iteration time because it will shorten the communication delay and number of smaller iterations required.
When unsure, go meta and iterate over the iteration time. Introduce small changes that could benefit your iteration time and see what happens. Depending on the results go further, or revert back.
Always, always put a version field on everything
Whenever you're designing API, persistent storage (database schemas, config file formats), network protocols, software design or anything like that: make sure you've included a version number somewhere giving you a path for iterating over it in the future: seamlessly introducing a new, improved version without breaking everything. Only this way you can guarantee that you have a way to iterate your design incrementally as you gain more real-world feedback, and not get dragged down forever by the sub-optimal initial design. This approach can also prevent a decision paralysis, over-engineering, and endless design meetings.
Interactive is the best iteration time
Being able to get feedback instantly, is the best place to be. It's especially self-evident when results are visual. Imagine painting a picture, where every strike of the brush requires 5 minutes compilation process to see the results. But it's not limited to graphics. Many times, we design systems like data processing, UIs, etc. where interactive is possible, but for whatever reason not considered. It's truly a shame, because very often fast feedback leads to entirely new class of use cases and ideas.
I hope you will find this idea useful, and iteration time considerations will stay with you, at least somewhere in the back of your head. Next time you will be making decisions about software development, software development process, etc. you will hopefully consider optimizing for it, and see the results for yourself.