[mig4ng]

> 15 minutes later you get a failed build notification. You need to switch back to the previous task, try to fix the issue … and go for another 15 minutes loop …

The 3 minute rule is probably one of the most important in the article in my opinion. I have worked with workflows that were longer than 3 minutes (10min+-) and I find that I either went do something unproductive or I started another task. The times when I started another feature and later got interrupted by the previous one because of this were probably 90% of them. This had major impact in my productivity.

Therefore I agree that the workflow should be as quick as possible in order for developers not to lose focus and the flow. The flow state boosts productivity by more than double for myself. And these notifications to go into the previous task break that flow more often than not.

Regarding working on a feature toggle oriented workflow I never had the privilege of working in such environment, but from what I read in this and other articles/books it provides a better work environment for the developers. If anyone has a project like this I would love to experience that and learn more about it.

[bullcitydev]

Not to hijack the OPs post, Fire CI looks like a great tool! I recently released my open source feature toggle project, Flipt (https://github.com/markphelps/flipt), that allows you to implement feature flags in your existing environment.

Would love for you to check it out and give any feedback that you can!

[jpdel]

Flipt is an interesting concept! I've tracked you down on Twitter. Let's talk when you have time ;)