Re^8: Beyond Agile: Subsidiarity as a Team and Software Design Principle

Replies are listed 'Best First'.
Re^9: Beyond Agile: Subsidiarity as a Team and Software Design Principle by chacham (Prior) on Jul 31, 2015 at 16:44 UTC
Huh? I think we're mixing up the tangent with the main discussion. The context is Waterfall vs Agile, specifically, quick releases. It was objected that requirements can and do change in unforeseeable ways and an example was proffered. I challenged the relevance of the example as the significant change happened long after the original design, to the point where it was not relevant to the method used for the original design process.	[reply]
Re^10: Beyond Agile: Subsidiarity as a Team and Software Design Principle by mr_mischief (Monsignor) on Jul 31, 2015 at 16:52 UTC
Who cares about the original design process? That code is written. You're advocating Waterfall. How would Waterfall be used to make the new version with the new requirements, given that there's already the existing code of the old version? What advantages would it give over one of the agile methodologies to get from the old version to the new version? Waterfall is a process designed to go from a blank slate to a finished product. Would you start from scratch, throwing away the old code? Would you try digging out the original design documents (which are not necessarily decades old) and altering them via some Waterfall process that now accounts for modifying existing code that was fully designed from the outset into a largely but not entirely new codebase? Or maybe you'd refactor pieces of the existing code, one after another, and test to make sure parts of the new functionality work as those parts are done every week or three?	[reply]
Re^11: Beyond Agile: Subsidiarity as a Team and Software Design Principle by chacham (Prior) on Jul 31, 2015 at 17:55 UTC
Who cares about the original design process? My comments were made within that context. You're advocating Waterfall. To be clear, my advocacy was "While Waterfall may have some problems, there's no reason to throw out the baby with the bathwater." What advantages would it give over one of the agile methodologies Who said it was better?	[reply]


Keep It Simple, Stupid
	PerlMonks