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

Replies are listed 'Best First'.
Re^3: Beyond Agile: Subsidiarity as a Team and Software Design Principle by chacham (Prior) on Jul 21, 2015 at 16:04 UTC
I disagree with the contention that requirements always change. I see it as a euphemism used to excuse laziness in gathering requirements. The requirements are what they are. In general, it is not a wishlist, rather, a specific problem or situation arises that requires resolution. Usually, that does not change. The changes i have seen have to do with the UI. They want it to do this, or because they had not seen it, they didn't realize they also needed that. The requirements haven't changed, the UI however, needs more revisions. In some cases, the requirements change often, because the situation demands it. In those scenarios, it is more efficient to follow the Un*x paradigm of separate tools. Each one, however, would be design completely before being coded.	[reply]
Re^4: Beyond Agile: Subsidiarity as a Team and Software Design Principle by einhverfr (Friar) on Jul 22, 2015 at 00:02 UTC
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.	[reply]
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]
Re^4: Beyond Agile: Subsidiarity as a Team and Software Design Principle by BrowserUk (Patriarch) on Jul 22, 2015 at 23:45 UTC
I disagree with the contention that requirements always change. I see it as a euphemism used to excuse laziness in gathering requirements. You are living in cloud cuckoo land. Read this. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!	[reply]
Re^5: Beyond Agile: Subsidiarity as a Team and Software Design Principle by chacham (Prior) on Jul 23, 2015 at 13:20 UTC
So, to respond to a thought on requirements, you respond with limitation of hardware vis-a-vis programs for rockets. Perhaps apropos: Requirements are not rocket science! :)	[reply]
Re^6: Beyond Agile: Subsidiarity as a Team and Software Design Principle by BrowserUk (Patriarch) on Jul 23, 2015 at 15:28 UTC
Re^7: Beyond Agile: Subsidiarity as a Team and Software Design Principle by chacham (Prior) on Jul 23, 2015 at 18:09 UTC
Some notes below your chosen depth have not been shown here
Re^4: Beyond Agile: Subsidiarity as a Team and Software Design Principle by mr_mischief (Monsignor) on Jul 24, 2015 at 17:13 UTC
In many cases requirements won't change between beginning on a particular release and the release date, but in many cases they will. Either way, from one release to the next things almost always change. Otherwise, why release again? You actually get fewer of these changes per release if you release more often. That minimizes scope creep during the release. Also, people who think a UI is not part of the requirements obviously are not responsible for UI or UX development.	[reply]
Re^5: Beyond Agile: Subsidiarity as a Team and Software Design Principle by chacham (Prior) on Jul 27, 2015 at 13:19 UTC
in many cases they will But what changes? The approach, the rules, or the UI? Otherwise, why release again? To ensure the team's existence. It is sad how often this is the primary motivator in large companies. You actually get fewer of these changes per release if you release more often. That minimizes scope creep during the release. Customer fatigue over changes? Customers generally do not like change in their routines. Release more often and they dread any changes that aren't the bare minimum of what they asked for. New releases also tend to break things.	[reply]
Re^6: Beyond Agile: Subsidiarity as a Team and Software Design Principle by mr_mischief (Monsignor) on Jul 27, 2015 at 15:42 UTC
Re^7: Beyond Agile: Subsidiarity as a Team and Software Design Principle by Your Mother (Archbishop) on Jul 27, 2015 at 16:27 UTC
Some notes below your chosen depth have not been shown here
Re^7: Beyond Agile: Subsidiarity as a Team and Software Design Principle by chacham (Prior) on Jul 27, 2015 at 16:06 UTC
Some notes below your chosen depth have not been shown here
Re^4: Beyond Agile: Subsidiarity as a Team and Software Design Principle by mr_mischief (Monsignor) on Jul 29, 2015 at 20:34 UTC
The requirements are what they are. In general, it is not a wishlist, rather, a specific problem or situation arises that requires resolution. Usually, that does not change. The above sounds much like someone who's never written business software that handles any sort of legally regulated process, anything covering policy issues at a large company, or anything that interfaces with third-party software. Tax codes change. Building codes change. Profit, loss, and expense reporting policies change. Configuration file formats change. The APIs of other packages change. Data interchange formats change. Acceptable cipher suites change. There are only two types of software that never change once written. One is software discarded because it didn't meet the original need sufficiently. The other is software that is obsoleted because it didn't support the changes around it and wasn't considered worth updating. If you want to write software that never changes then basically your goal is to write software that fails. What kind of goal is that?	[reply]
Re^5: Beyond Agile: Subsidiarity as a Team and Software Design Principle by chacham (Prior) on Jul 30, 2015 at 14:04 UTC
he above sounds much like someone who's never written business software that handles any sort of legally regulated process One project i was on was to enforce the rules of internal security and audits on ~8,000 servers and clients (iiuc, at least twice that now.) To address this, and to support changing rules and system administrator preferences, the client itself was designed with different types of enforcements, but the actual rules were sent to the clients in a separate file. Luckily, we got to do it in Perl. There, forethought was used to design to address anticipated changes. I have worked with him many times, and have seen that he always uses that approach, that is, to expect change. Other people approach things by designing software to the specifics of the request (as opposed to designing toward the underlying issue.) Although i believe this approach to be fundamentally flawed, that's just my opinion. Regardless, Agile will definitely help them.	[reply]
Re^6: Beyond Agile: Subsidiarity as a Team and Software Design Principle by mr_mischief (Monsignor) on Jul 30, 2015 at 19:45 UTC
Re^7: Beyond Agile: Subsidiarity as a Team and Software Design Principle by Your Mother (Archbishop) on Jul 30, 2015 at 20:18 UTC
Re^7: Beyond Agile: Subsidiarity as a Team and Software Design Principle by chacham (Prior) on Jul 31, 2015 at 12:36 UTC
Some notes below your chosen depth have not been shown here
Re^4: Beyond Agile: Subsidiarity as a Team and Software Design Principle by mr_mischief (Monsignor) on Jul 29, 2015 at 20:34 UTC
The requirements are what they are. In general, it is not a wishlist, rather, a specific problem or situation arises that requires resolution. Usually, that does not change. The above sounds much like someone who's never written business software that handles any sort of legally regulated process, anything covering policy issues at a large company, or anything that interfaces with third-party software. Tax codes change. Building codes change. Profit, loss, and expense reporting policies change. Configuration file formats change. The APIs of other packages change. Data interchange formats change. Acceptable cipher suites change. There are only two types of software that never change once written. One is software discarded because it didn't meet the original need sufficiently. The other is software that is obsoleted because it didn't support the changes around it and wasn't considered worth updating. If you want to write software that never changes then basically your goal is to write software that fails. What kind of goal is that?	[reply]