I have some sympathy with that view. I thought it important though that the new API gave the power to avoid generating more routes than was required, and without too much code. But see it as an intermediate step to #6, which does the job of the old API but with a lot more power there at your disposal if you need it.

With hindsight my bigger regret is that I didn’t name methods named after the HTTP methods GET, PUT, POST, DELETE etc. But that’s another story…

This definitely can be considered par for Rails, if that is your motivation, in that it is so narrow, so specific, so presumptive and so magical that unless one programs under the very fragile and particular conditions for which this solution is best suited, it’s going to be break. And because it’s so magical, unpacking its behavior and attempting to understand the process deeply is going to be an exercise in both spelunking and mind-reading.

Python is definitely about being explicit.

Yes a set of Kanban principles would be a good thing but I wouldn’t necessarily want it to represent a breakaway from Agile. But perhaps it would be an appropriate challenge to the whole community if we could come up with a set that takes on board what we’ve all learned in the intervening years. Current efforts that are even more prescriptive (assuming iterations for example) are a backward step.

Maybe its time for a set of kanban principles?

I think the change in focus to business value over working software is a good one, all too often IT abdicates responsibility for business sucess, kanban and lean’s switch in emphasis to value and flow provide us with tools to step into the “scary” business world and be accountable to value.

Enterprise - This usually means the people doing the work are left to try and get things done under a 5000lbs wet blanket of bureaucracy.