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 reply to Re^6: Beyond Agile: Subsidiarity as a Team and Software Design Principle by BrowserUk
in thread Beyond Agile: Subsidiarity as a Team and Software Design Principle by einhverfr

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.