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

I disagree with the contention that requirements always change. I see it as a euphemism used to excuse laziness in gathering requirements.

Yes and no.

I have never worked on a complex project where requirements didn't change either due to regulatory changes (the IRS puts out additional reporting requirements for example), other technological changes (cost of gene sequencing goes way down so quantity of data goes way up), or business changes ("we want to get into a new market"). These are real requirement changes and they happen.

But part of my point is that on the other hand, people use this as an excuse for laziness in design. Yes, requirements will change. No, you can't always foresee how. But you can with some experience have at least some idea which parts of your project are most likely to be most affected.

If you pay attention to that question then you can make sure that when requirements change (and they will) that the need to re-architect the software is limited because many components are as you described -- technically limited, bounded in responsibility, there to solve a well defined problem.

If there is disagreement here it is with the word "completely." There are all kinds of design decisions one makes while coding and so completion of the design process is only possible at that point (and probably not set in stone until after the initial *testing* process if we are not afraid to go back and revisit decisions). The interfaces will be completely defined but the internals may not be before the coding process begins (this is what I call "work ownership"). Otherwise you have already done your coding....

So what I am arguing is that small teams with defined responsibilities are best equipped to design, develop, and test their own small pieces as deliverables to other teams. I don't actually think we are in substantive disagreement, just quibbling about a few words here and there.

Comment on Re^4: Beyond Agile: Subsidiarity as a Team and Software Design Principle

Replies are listed 'Best First'.

Re^5: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by chacham (Prior) on Jul 22, 2015 at 12:55 UTC

At this point, i think we're going to disagree more in approach than anything else, though as you have pointed out, there's some overlap where we agree in principle.

Someone once asked me (assumed?) if i design data models to directly address the application. I told him absolutely not, as that was a recipe for failure. Over time, requirements change, applications change, (but data is forever :)) and a good database design for this is absolutely terrible for that.

So, how do i design a data model? I aim for the idea and build a model around that. When i have a consistent model, it is expanded (as opposed to patched) to include the current application's data requirements. Then, when "requirements change", there is little, if any, change required to the data model. That is the benefit of designing to the idea rather than to the current application manifestation.

Applications are much more closely tied to the user experience, and are thus less likely to be able to use this approach. Though, as you put it, "with some experience have at least some idea which parts of your project are most likely to be most affected." I think it is much more than that. With experience, you can design most of your application into separate modules (or whatever fits in that environment) to allow modification. And even then, it is usually limited to the UI and not the engine that runs it.

I don't think the requirements have changed though. Requiring new reports simply means a new query need be written, IRS rules (which are known about well before they apply) simply mean another check or two is added, and data quantity should rarely affect a large project. Sure, some details were added or modified, but if that requires a redesign, someone failed to do a proper design.

[reply]


Perl Monk, Perl Meditation
	PerlMonks