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

Nice article, though i completely disagree. While Waterfall may have some problems, there's no reason to throw out the baby with the bathwater.

The Waterfall method is not just to get requirements and start coding. Waterfall works within the overall code writing process, which includes designing the code itself. Pseudocode is the best way to do it, though it unfortunately is unpopular. The idea is, get the requirements, find a solution (specification), design the code (pseudocode), and then code flawless software.

The major issue here is not the coding. It is that the customers rarely know what they want. They think they do, but they don't. They'll know it when they see it. So, they sign off on a requirements document, without really knowing what the product will be. The issue, however, is not the requirements document. It's that the requirements and specifications are often converged into one document. That's bad.

The solution to that is to have both a requirements document and a specification document. But, what are they? A requirements documents states the problem that needs solving, and a determination of what is required to solve it. Hence the name requirements. It is written by the customer, as it is their way of communication what they need. For example: we need an accounting system to handle internal spending. Then go into details about the requirements, not the solution. Meetings are then had to understand the requirements. When the document is completely understood, it should need no further change.

The specification document is completely different. First, it is written by the development (or UI) team. It specifies a solution, including things like mockup screenshots and anything else that the customer will interface with. No backend information need be mentioned, unless the customer will be using that too. This document specifies how it will respond and what it will produce.

Often, this is called a Use Case document. However, Use Cases are subsidiary to the specification. The specification mentioned every aspect, whereas Use Case to a subset of them. Though, enough Use Case documents could be used in lieu of a specification.

The specification document generally goes through many cycles. Alternatively, mockups can go through the cycles with a specification document written at the end. Either way, there are many cycle. The Agile method has much to offer here. Design the UI quickly, and with the customer involved every step of the way. The customer will see it, experience it, and respond. Now the customers know what they want, and can agree to the final look.

After that, design is done. Design the data model, if there is one, and how the code will work. And go from there. As the customer doesn't care how it works, reviewing the various phases with the customer achieves nothing. Just release it when it is done.

Overall, Waterfall works well. However, if the steps are not followed, nothing will work. All Agile does is minimize the damage, but takes longer and works against consistency in the backend.

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

Replies are listed 'Best First'.
Re^2: Beyond Agile: Subsidiarity as a Team and Software Design Principle by einhverfr (Friar) on Jul 21, 2015 at 15:27 UTC
I think there are two problems with the waterfall approach. The first is that it separates either by team or by time design from development. One thing that is hard to learn except from experience is where and when things should be designed first or left for later. This doesn't mean always one or the other.... The second is that requirements always change, but they don't always change in the same way. Again, this is domain-specific. So the waterfall method as I point out, is applicable in some cases. What I see you say though is that one does need to design before coding. This I agree with. That a waterfall in miniature is helpful. This I agree with too. So I am not actually sure where we disagree. The point of subsidiarity is to ensure that design and coding are closely tied both by team and by time, and that the pieces are small enough that the design can be done right. That has a lot in common with both waterfall and agile methodologies.	[reply]
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
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
Re^6: Beyond Agile: Subsidiarity as a Team and Software Design Principle by BrowserUk (Patriarch) on Jul 23, 2015 at 15:28 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
Re^6: Beyond Agile: Subsidiarity as a Team and Software Design Principle by mr_mischief (Monsignor) on Jul 27, 2015 at 15:42 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
Re^6: Beyond Agile: Subsidiarity as a Team and Software Design Principle by mr_mischief (Monsignor) on Jul 30, 2015 at 19:45 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^2: Beyond Agile: Subsidiarity as a Team and Software Design Principle by jeffa (Bishop) on Jul 21, 2015 at 17:32 UTC
I see Waterfall as an unsuited methodology for software development. I see Agile as an improvement. In my experience, Waterfall does not work well because requirements are rapidly changing. Yes they are. Yes they are. The idea is to simply decrease the amount of time it takes to deliver features and fixes by reducing the iteration cycle to adjust for these rapidly changing requirements we software developers face. Stake holders must be on board, for it is they who sign off on which features and fixes to prioritize. Automation and tests with high value are also key. But let's check some history, shall we? Read up on Winston_W._Royce , the important quote i wish to point out is 'According to Royce in the process model "the design iterations are never confined to the successive step", and for that model without iteration is "risky and invites failure". As alternative Royce proposed a more incremental development, where every next step links back to the step before.' And isn't that what Agile strives to be? More incremental? More immediate feedback? This is just evolution of software deployment. jeffa L-LL-L--L-LL-L--L-LL-L-- -R--R-RR-R--R-RR-R--R-RR B--B--B--B--B--B--B--B-- H---H---H---H---H---H--- (the triplet paradiddle with high-hat)	[reply]
Re^3: Beyond Agile: Subsidiarity as a Team and Software Design Principle by einhverfr (Friar) on Jul 22, 2015 at 00:08 UTC
I see Waterfall as an unsuited methodology for software development. I see Agile as an improvement. In my experience, Waterfall does not work well because requirements are rapidly changing. Yes they are. Yes they are. But they aren't always. Consider embedded development of computers controlling cars, or things like control software for radiotherapy. Bugs there can cost lives and the requirements are well defined, so full-blown waterfall processes are appropriate. Moreover they aren't rapidly changing for all parts of a project. Usually with a little experience you can identify those areas where requirements are likely to change most. If everything else is well componentized, up-front design really isn't a bad thing. And if the components are small, iterations don't need to be long. That's why subsidiarity is important, because it focuses on the design and development of small components by small teams, not big nebulous projects by very unstructured teams. A project may have a part of that but the more contained your rapidly evolving requirements are the quicker you can deliver them.	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.