7 ms·

It's fun to watch observations like the following re-discovered again and again. From the NATO Software Engineering Conference in 1968: Ross: The most deadly t

It's fun to watch observations like the following re-discovered again and again. From the NATO Software Engineering Conference in 1968: Ross: The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. Fraser: One of the problems that is central to the software production process is to identify the nature of progress and to find some way of measuring it. Only one thing seems to be clear just now. It is that program construction is not always a simple progression in which each act of assembly represents a distinct forward step and that the final product can be described simply as the sum of many sub-assemblies. (Full transcript of the 1968 conference here. http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PD... It's a really fun read!)

emddudley 13y ago
The 1968 NATO SE conference is also the earliest reference I know of discussing software reuse (page 79 of the PDF, "Mass Produced Software Components"). Interesting to see how some of the problems then are still problems today.
- mcguire 13y ago
  Some?
  - Retric 13y ago
    "The only things that really changed over the last 30 plus years is computers are a lot faster and people are dumber." -Old Coder
  - emddudley 13y ago
    I think that the success of open source libraries shows how software reuse can work rather well. However when designing a new library it is still (and may always be) difficult to "parameterize" (to use McIlroy's term) in the most useful way for your users.
  - acdha 13y ago
    Things which are a LOT easier: 1. Interactive editing 2. Interactive compilation (these two are probably the biggest reason programmers now are more productive) 3. Having enough storage for most problems 4. Having enough computation to solve most problems interactively 5. Handling numbers larger than one machine word 6. Handling floating point numbers 7. Handling precise decimal numbers (except for the lucky few using mainframes / COBOL) 8. Handling text using characters which wouldn't have worked in a telegram 9. Exchanging text with other systems (you couldn't even assume ASCII with other encodings (e.g. EBCDIC) being common) 10. Tracking changes to source code 11. Distributing shared code and tracking new releases 12. Communicating with other systems We've gotten a lot better on various technical details. The parts which remain difficult are generally different aspects of human limitations reasoning about complex systems.
- twobits 13y ago
  May not be a problem for them any more..
vonmoltke 13y ago
Ironically, it is military software projects that are some of the the worst examples of what Ross and Fraser warned about.
DenisM 13y ago
Having read "the mythical man-month" I came to conclusion that majority of the problems we have today were discovered an described by the 1970-ies.
- mathattack 13y ago
  Great book. He anticipates a lot of the problems, and "Adding idiots at the end" rarely fixes things. (Look at the Obamaacare website) It's been a while since I've read it, but I don't think he captured the benefits from agility.
  - taeric 13y ago
    I would not be surprised to find that someday we understand why some projects work from agile, and see that it basically comes back to the "vision" observation in Mythical Man Month. Of course, this really just betrays that I want that to happen. So... take it for what its worth.
  - jerf 13y ago
    He mentions the importance of automated tested once or twice I think, but it isn't hammered on as a modern Agilist would. But, remember, 1970 was a different world. You may literally have not had room to include unit tests in your code, or literally be unable to afford the sort of abstractions that would enable unit testing, for instance.Other parts of that book talk about the difficulty of squeezing bytes out of pages. A lot of modern Agile practices are not possible back then, or are so different as to be entirely different things. TDD would probably get laughed at by all, for instance. "What, you want me to waste my precious timeshare time to run tests I know are going to fail?"
    - pnathan 13y ago
      I don't have the reference, but I read somewhere several years ago when digging through old journals that regular testing was part of the Project Mercury? Gemini? software development process.
0xdeadbeefbabe 13y ago
Alan Kay suggested we have these problems because computer science is more like pop culture than science. http://www.youtube.com/watch?v=FvmTSpJU-Xc http://www.youtube.com/watch?v=FvmTSpJU-Xc
jshen 13y ago
Imagine you are a large company and there are 10 ideas for things you can build next, and you can't do them all. You gather the people that build such things and ask them, "how much will it cost to make each of these, and how long will it take". Do you think it is an acceptable answer if the builders reply, "I have no idea how much it will cost, I don't know how long it will take, and I don't know what you will have at the end of the process." How should a business handle this problem?
- aidenn0 13y ago
  You can answer with order of magnitude approximations (days, months, years, might be impossible). The order of magnitude approximation is good enough, and for ones in which you can't make an order of magnitude approximation you should be able to back it up. e.g. c.a. 2002 a PMM said "All we need for this idea to work is speaker-independent voice recognition in a noisy environment; how long will that take?" The correct answer to that question isn't a time estimate, or "I don't know" it's saying that doing so is an R&D problem, not an engineering problem.
- ebiester 13y ago
  I can't give you an exact cost and time, but what I can do is give you relative cost and time. "This is easy, this is easy but will take a while (low variance), this is hard (relatively long time, high variance.) -- so that's giving you your estimate and your tolerances. Further, I can work with you to figure out what portion of each project will give you the biggest bang for your buck. So you can say, "I want to spend x00,000 dollars." -- and I come back and give you a demo each week that you can play around with. At any point, you can say, "This is enough to generate value for me, let's move to the next thing for a while." Further still, I can build it with enough test coverages and good design practices that it will be possible to extend upon the design at a later point without scrapping everything. On the other hand, you can spend half of that x00,000 developing a specification. If detailed enough, I can give you a very low variance estimate of how long it will take. However, you won't know if it will actually meet your needs until you see it. You won't know about problems in what you really need until it's too late, and you'll end up spending more money in the end. That's the message that should go out.
lifeisstillgood 13y ago
And the answer is ... ? :-)

emddudley 13y ago

The 1968 NATO SE conference is also the earliest reference I know of discussing software reuse (page 79 of the PDF, "Mass Produced Software Components"). Interesting to see how some of the problems then are still problems today.

mcguire 13y ago
Some?
- Retric 13y ago
  "The only things that really changed over the last 30 plus years is computers are a lot faster and people are dumber." -Old Coder
- emddudley 13y ago
  I think that the success of open source libraries shows how software reuse can work rather well. However when designing a new library it is still (and may always be) difficult to "parameterize" (to use McIlroy's term) in the most useful way for your users.
- acdha 13y ago
  Things which are a LOT easier: 1. Interactive editing 2. Interactive compilation (these two are probably the biggest reason programmers now are more productive) 3. Having enough storage for most problems 4. Having enough computation to solve most problems interactively 5. Handling numbers larger than one machine word 6. Handling floating point numbers 7. Handling precise decimal numbers (except for the lucky few using mainframes / COBOL) 8. Handling text using characters which wouldn't have worked in a telegram 9. Exchanging text with other systems (you couldn't even assume ASCII with other encodings (e.g. EBCDIC) being common) 10. Tracking changes to source code 11. Distributing shared code and tracking new releases 12. Communicating with other systems We've gotten a lot better on various technical details. The parts which remain difficult are generally different aspects of human limitations reasoning about complex systems.
twobits 13y ago
May not be a problem for them any more..

vonmoltke 13y ago

Ironically, it is military software projects that are some of the the worst examples of what Ross and Fraser warned about.

DenisM 13y ago

Having read "the mythical man-month" I came to conclusion that majority of the problems we have today were discovered an described by the 1970-ies.

mathattack 13y ago
Great book. He anticipates a lot of the problems, and "Adding idiots at the end" rarely fixes things. (Look at the Obamaacare website) It's been a while since I've read it, but I don't think he captured the benefits from agility.
- taeric 13y ago
  I would not be surprised to find that someday we understand why some projects work from agile, and see that it basically comes back to the "vision" observation in Mythical Man Month. Of course, this really just betrays that I want that to happen. So... take it for what its worth.
- jerf 13y ago
  He mentions the importance of automated tested once or twice I think, but it isn't hammered on as a modern Agilist would. But, remember, 1970 was a different world. You may literally have not had room to include unit tests in your code, or literally be unable to afford the sort of abstractions that would enable unit testing, for instance.Other parts of that book talk about the difficulty of squeezing bytes out of pages. A lot of modern Agile practices are not possible back then, or are so different as to be entirely different things. TDD would probably get laughed at by all, for instance. "What, you want me to waste my precious timeshare time to run tests I know are going to fail?"
  - pnathan 13y ago
    I don't have the reference, but I read somewhere several years ago when digging through old journals that regular testing was part of the Project Mercury? Gemini? software development process.

0xdeadbeefbabe 13y ago

Alan Kay suggested we have these problems because computer science is more like pop culture than science. http://www.youtube.com/watch?v=FvmTSpJU-Xc http://www.youtube.com/watch?v=FvmTSpJU-Xc

jshen 13y ago

Imagine you are a large company and there are 10 ideas for things you can build next, and you can't do them all. You gather the people that build such things and ask them, "how much will it cost to make each of these, and how long will it take". Do you think it is an acceptable answer if the builders reply, "I have no idea how much it will cost, I don't know how long it will take, and I don't know what you will have at the end of the process." How should a business handle this problem?

aidenn0 13y ago
You can answer with order of magnitude approximations (days, months, years, might be impossible). The order of magnitude approximation is good enough, and for ones in which you can't make an order of magnitude approximation you should be able to back it up. e.g. c.a. 2002 a PMM said "All we need for this idea to work is speaker-independent voice recognition in a noisy environment; how long will that take?" The correct answer to that question isn't a time estimate, or "I don't know" it's saying that doing so is an R&D problem, not an engineering problem.
ebiester 13y ago
I can't give you an exact cost and time, but what I can do is give you relative cost and time. "This is easy, this is easy but will take a while (low variance), this is hard (relatively long time, high variance.) -- so that's giving you your estimate and your tolerances. Further, I can work with you to figure out what portion of each project will give you the biggest bang for your buck. So you can say, "I want to spend x00,000 dollars." -- and I come back and give you a demo each week that you can play around with. At any point, you can say, "This is enough to generate value for me, let's move to the next thing for a while." Further still, I can build it with enough test coverages and good design practices that it will be possible to extend upon the design at a later point without scrapping everything. On the other hand, you can spend half of that x00,000 developing a specification. If detailed enough, I can give you a very low variance estimate of how long it will take. However, you won't know if it will actually meet your needs until you see it. You won't know about problems in what you really need until it's too late, and you'll end up spending more money in the end. That's the message that should go out.

lifeisstillgood 13y ago

And the answer is ... ? :-)