How do teams efficiently manage continuously changing requirements and maintain continuous delivery?

@libby Process plus design, and process plus tools, respectively.

Managing requirements change is partly about pushing back on requirements to make sure that the thing they asked for is the thing they need, not the thing they think they need. The other half of that is having a good enough understanding of the domain to know what parts of the system are likely to change and how, then making sure the code is well factored to change in those ways.

Continuous Delivery is more about having the tooling set up to actually do it, and a strict/thorough enough testing process to be confident that you're not just breaking builds all the time.

@JoelHarmon is what you're saying consistent with Agile methodologies to embrace change?

@libby I often think it's narrowing down what won't change in the design so that you limit the moving targets.

@libby Design is about commitment as I see it. Even the digital mediums we have won't afford an artist to change his mind about the composition of a painting without redoing all or most of it. The key parts as I see it is to boil down what won't change in a world that constantly demands changes. The more you can pour cement over, set in stone, the less chaotic the entire process will be.

If I go into a more controversial category, IMO one of the problems with OOP is the assumption that logic is more stable than data. That's not always the case, depending on the problem at hand. Sometimes a game engine ,for example, can commit to the idea of using single-precision 32-bit floats everywhere more easily (ex: for transformation matrices) than deciding what to do with them. The dependencies should flow towards the most stable (unchanging) aspects of your design.

The more the dependencies flow towards stable (unchanging, cemented in concrete, clay baked in the oven) parts of your design, the more readily and easily you can adapt to unanticipated design changes in the moving parts without costly rewrites.

Well I guess these rewrites are twice as costly because I also need to rewrite all my tests!

Which is basically what has paralyzed me today. I haven't even been able to write tests because I'm so worried about making a mistake that will cost me to fix up when it really shouldn't cost me very much at the current size of my project.

If we're rewriting our tests frequently, then it's a sign IMO that our dependencies don't flow towards stability.

What do you mean by "dependencies"

Basically coupling -- for something to depend on something else and to be a certain way, put crudely.

Like a skyscraper depending on a sturdy foundation to avoid collapsing.

"Afferent couplings" if we go by Uncle Bob terms.

I always confuse afferent and efferent.

But just in terms of broad design, I'm thinking mostly about things that won't change. We depend on the things that won't change. If a guy marries a woman or vice versa and makes that commitment, they depend on ideas that won't change. If their partner turns out to be completely different one day from the one they loved, they have to redo their whole conceptual model of the world. If an artist is commissioned to make painting of lions, and the client changes his mind and says tigers...

... chances are that the artist will have to redo most if not all of his/her work because he/she depended on (had dependencies upon) the idea of painting lions.

So in my mind, the key process of design is to figure out what won't change. Not what will. It's figuring out the constants in a world full of variables.

The more you figure out as constant/immutable as far as the design goes, the less grief you have in a world that shifts under our feet. I might be a bit skewed on this one. I work in the computer graphics industry which makes yesterday's techniques obsolete each passing year. But the key I've found to keeping teams staying relatively agile is to maximize the number of design assumptions that will not change in the future. I have some C code I still use from the 1980s. Keeps me competitive.

@libby I'd say that defining some things that won't change and some that will is definitely compatible with an agile mindset. A huge example that comes to mind is the programming language you're using. Is it reasonable to be willing to change that at any point in the project? Typically no.