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.

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.

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.

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! :)

to respond to a thought on requirements, you respond with limitation of hardware vis-a-vis programs for rockets.

Wow. Is that what you read?

What I read was, that the single most carefully designed and specified software project in history had to deal with changes to its requirements throughout its 30 year lifespan.

Despite setting out with the goals of:

These lessons were applied to the Shuttle. One of the most important lessons was that software is more difficult to develop than hardware. As a result,
• software documentation is crucial,
• verification must proceed through a sequence of steps without skipping any to try to save time,
• requirements must be clearly defined and carefully managed,
• good development plans should be created and followed, and
• adding more programmers does not lead to faster development.

NASA also learned to assign experienced personnel to a project early, rather than using the start of a project for training inexperienced personnel.

And having 6 years of research & development time, and spending $200,000,000:

A second challenge involved requirements. The software requirements for the Shuttle were continually evolving and changing, even after the system became operational and throughout its 30-year operational lifetime. Although new hardware components were added to the Shuttle during its lifetime, such as GPS, the Shuttle hardware was basically fixed and most of the changes over time went into the computers and their software. NASA and its contractors made over 2,000 requirements changes between 1975 and the first flight in 1981. Even after first flight, requirements changes continued. The number of changes proposed and implemented required a strict process to be used or chaos would have resulted.

I guess its true what they say about those that will not see; or at least only see what they want to see.

---

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". I knew I was on the right track :)

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!

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.

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.

Why give the customer more than the bare minimum they asked for? Why spend more time developing software than you're getting paid to spend?

If your new releases break things, that's a process problem. Try unit testing and integration testing. Everything that works in the old release should work in the new one.

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?

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.

So what you're saying is that projects such as going from remitting information in form ICD-9 to form ICD-10 in the healthcare and health insurance industry in the US should have involved no programming at all, because software developers should have foreseen the need to switch from a few hundred simple condition codes to several thousand codes in a new recursive data format? A new data format whose printed specification manual is over five inches thick and costs $1500?

If you're handling changes like that in a basic configuration file, then your powers of foresight are far beyond anyone in the entire healthcare industry. It was a months-long project most places to handle the new standard properly.

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?