Iterative Waterfall

I’ve found that, to do a large amount of high-quality work, employing something like the iterative waterfall has proven to be quite useful.

How this works is that, on a given day, I decide the main project that I’m going to work on. I spend a pretty large chunk of time narrowing down the requirements, testing, architecture, and so on. Once I’m happy with everything, I get a team of agents to build the thing end to end. This execution might take a few hours to a few days, and while that is going on, I can work on a few other waterfalls for other projects.

When the first project that I applied the waterfall to is complete, I review everything. This review itself is like a waterfall. It takes a while, but it is not bad. After the review, I decide what parts of it to merge as PRs and what parts of it need more work. This repeats for a few cycles.

The main advantage of this mode of working is that my attention is better protected and I also got more work done. If I work on just a single thing at a single point in time, I’m waiting for agents to finish their work for too long, and it’s not the best use of my time. If I’m doing too many projects in parallel, my attention gets really scattered, and I lose the state of flow. I feel not so good.

Over the last few years of experimentation, I think this iterative waterfall model is working pretty well for me.