4 ms·

Current software engineers are roughly equivalent, in terms of field maturity, with the 'doctors' who put leeches on people in order draw out bad humors. This

Current software engineers are roughly equivalent, in terms of field maturity, with the 'doctors' who put leeches on people in order draw out bad humors. This isn't an insult, rather it's just amazing to have been around during this phase. Also, interviewing reflects this maturity.

rimantas 16y ago
I imagine doctors would gladly trade this maturity to the luxury software engineers have: having build everything themselves. Alas, a lot in modern medicine is not really much better than putting leeches, hence the articles "X is good for your health" and then two weeks later "or maybe not". You can compare medics to a bunch of programmers which have to maintain billions copies of self-replicating and self-modifying program with billions year old legacy code. No source code is available, only obsfucated fragments without clear understanding which bits are significant and which just junk. Disassembly is hard, and no debug is possible, so the only way to figure out how the system works is try to modify a bit and look how the output changes. Some defects manifest quite often and there are few bugfixes ready, but how they work and what side-effects they have is not always clear. Systems are very fragile and must be treated very carefully in order to avoid fatal crash. Hence the "maturity" of the field — one has to be very careful when dealing with the staff not fully understood.
barry-cotter 16y ago
Current software engineers are roughly equivalent, in terms of field maturity, with the 'doctors' who put leeches on people in order draw out bad humors Balls. The medical profession killed more people than it cured until some time between the 1930s and 1950s with the discovery of antibiotics. Walmart's supply chain management software alone has bdone more good than the entirety of the medical profession up to 19##.
- bluesnowmonkey 16y ago
  Considering that only 16% of software projects are completed on time and under budget [1], I'd say we kill more people than we cure, too, metaphorically speaking. [1]: http://www.projectsmart.co.uk/docs/chaos-report.pdf http://www.projectsmart.co.uk/docs/chaos-report.pdf
- georgieporgie 16y ago
  I wasn't talking about public good, I was talking about relative maturity within a field.
- raganwald 16y ago
  Walmart's supply chain management software This is what we call cherry-picking an example. Someone who wanted to argue with you might select Windows autorun and its role in the world of illicit botnets and keyboard logging.
  - barry-cotter 16y ago
    Autorun bad and all, but Windows was pretty obviously a huge win as a productivity multiplier. I'd be kind of surprised if Windows hasn't done more for GDP[1] than Walmart. Practically any commercial software package ever sold probably had a greater positive effect on the world than pre 19## medicine. This will hold more strongly for shrinkwrap software that stays around long enough for the company producing it to build a rep. [1]Or total world utility/happiness, if we could measure that
nl 16y ago
This is a very common meme, but there is some evidence to show that is isn't true. Most fields (including software engineering) are pretty good at solving problems that have previously been solved. Generally speaking civil engineers are pretty good at building bridges that stay up for example (with occasional exceptions of course!). Similarly, software engineers are pretty decent at building accounting systems etc. When any field attempts to do something new, software engineering is pretty much as good as any other field. Even fields as mature as mechanical engineering make mistakes. For example, the space shuttle Challenger disaster was caused by defective O-ring seals, and delusional engineering management who systematically ignored warnings. Richard Feynman (who knew something about building systems at the edge of what was possible) said the following, when comparing the software engineering process with other processes inside NASA: The software is checked very carefully in a bottom-up fashion. First, each new line of code is checked, then sections of code or modules with special functions are verified. The scope is increased step by step until the new changes are incorporated into a complete system and checked. This complete output is considered the final product, newly released. But completely independently there is an independent verification group, that takes an adversary attitude to the software development group, and tests and verifies the software as if it were a customer of the delivered product. There is additional verification in using the new programs in simulators, etc. A discovery of an error during verification testing is considered very serious, and its origin studied very carefully to avoid such mistakes in the future. Such unexpected errors have been found only about six times in all the programming and program changing (for new or altered payloads) that has been done. The principle that is followed is that all the verification is not an aspect of program safety, it is merely a test of that safety, in a non-catastrophic verification. Flight safety is to be judged solely on how well the programs do in the verification tests. A failure here generates considerable concern. To summarize then, the computer software checking system and attitude is of the highest quality. There appears to be no process of gradually fooling oneself while degrading standards so characteristic of the Solid Rocket Booster or Space Shuttle Main Engine safety systems. To be sure, there have been recent suggestions by management to curtail such elaborate and expensive tests as being unnecessary at this late date in Shuttle history. This must be resisted for it does not appreciate the mutual subtle influences, and sources of error generated by even small changes of one part of a program on another. There are perpetual requests for changes as new payloads and new demands and modifications are suggested by the users. Changes are expensive because they require extensive testing. The proper way to save money is to curtail the number of requested changes, not the quality of testing for each. http://history.nasa.gov/rogersrep/v2appf.htm http://history.nasa.gov/rogersrep/v2appf.htm Edit, TL;DR: To summarize then, the computer software checking system and attitude is of the highest quality. There appears to be no process of gradually fooling oneself while degrading standards so characteristic of the Solid Rocket Booster or Space Shuttle Main Engine safety systems.

rimantas 16y ago

I imagine doctors would gladly trade this maturity to the luxury software engineers have: having build everything themselves. Alas, a lot in modern medicine is not really much better than putting leeches, hence the articles "X is good for your health" and then two weeks later "or maybe not". You can compare medics to a bunch of programmers which have to maintain billions copies of self-replicating and self-modifying program with billions year old legacy code. No source code is available, only obsfucated fragments without clear understanding which bits are significant and which just junk. Disassembly is hard, and no debug is possible, so the only way to figure out how the system works is try to modify a bit and look how the output changes. Some defects manifest quite often and there are few bugfixes ready, but how they work and what side-effects they have is not always clear. Systems are very fragile and must be treated very carefully in order to avoid fatal crash. Hence the "maturity" of the field — one has to be very careful when dealing with the staff not fully understood.

barry-cotter 16y ago

Current software engineers are roughly equivalent, in terms of field maturity, with the 'doctors' who put leeches on people in order draw out bad humors Balls. The medical profession killed more people than it cured until some time between the 1930s and 1950s with the discovery of antibiotics. Walmart's supply chain management software alone has bdone more good than the entirety of the medical profession up to 19##.

bluesnowmonkey 16y ago
Considering that only 16% of software projects are completed on time and under budget [1], I'd say we kill more people than we cure, too, metaphorically speaking. [1]: http://www.projectsmart.co.uk/docs/chaos-report.pdf http://www.projectsmart.co.uk/docs/chaos-report.pdf
georgieporgie 16y ago
I wasn't talking about public good, I was talking about relative maturity within a field.
raganwald 16y ago
Walmart's supply chain management software This is what we call cherry-picking an example. Someone who wanted to argue with you might select Windows autorun and its role in the world of illicit botnets and keyboard logging.
- barry-cotter 16y ago
  Autorun bad and all, but Windows was pretty obviously a huge win as a productivity multiplier. I'd be kind of surprised if Windows hasn't done more for GDP[1] than Walmart. Practically any commercial software package ever sold probably had a greater positive effect on the world than pre 19## medicine. This will hold more strongly for shrinkwrap software that stays around long enough for the company producing it to build a rep. [1]Or total world utility/happiness, if we could measure that

nl 16y ago

This is a very common meme, but there is some evidence to show that is isn't true. Most fields (including software engineering) are pretty good at solving problems that have previously been solved. Generally speaking civil engineers are pretty good at building bridges that stay up for example (with occasional exceptions of course!). Similarly, software engineers are pretty decent at building accounting systems etc. When any field attempts to do something new, software engineering is pretty much as good as any other field. Even fields as mature as mechanical engineering make mistakes. For example, the space shuttle Challenger disaster was caused by defective O-ring seals, and delusional engineering management who systematically ignored warnings. Richard Feynman (who knew something about building systems at the edge of what was possible) said the following, when comparing the software engineering process with other processes inside NASA: The software is checked very carefully in a bottom-up fashion. First, each new line of code is checked, then sections of code or modules with special functions are verified. The scope is increased step by step until the new changes are incorporated into a complete system and checked. This complete output is considered the final product, newly released. But completely independently there is an independent verification group, that takes an adversary attitude to the software development group, and tests and verifies the software as if it were a customer of the delivered product. There is additional verification in using the new programs in simulators, etc. A discovery of an error during verification testing is considered very serious, and its origin studied very carefully to avoid such mistakes in the future. Such unexpected errors have been found only about six times in all the programming and program changing (for new or altered payloads) that has been done. The principle that is followed is that all the verification is not an aspect of program safety, it is merely a test of that safety, in a non-catastrophic verification. Flight safety is to be judged solely on how well the programs do in the verification tests. A failure here generates considerable concern. To summarize then, the computer software checking system and attitude is of the highest quality. There appears to be no process of gradually fooling oneself while degrading standards so characteristic of the Solid Rocket Booster or Space Shuttle Main Engine safety systems. To be sure, there have been recent suggestions by management to curtail such elaborate and expensive tests as being unnecessary at this late date in Shuttle history. This must be resisted for it does not appreciate the mutual subtle influences, and sources of error generated by even small changes of one part of a program on another. There are perpetual requests for changes as new payloads and new demands and modifications are suggested by the users. Changes are expensive because they require extensive testing. The proper way to save money is to curtail the number of requested changes, not the quality of testing for each. http://history.nasa.gov/rogersrep/v2appf.htm http://history.nasa.gov/rogersrep/v2appf.htm Edit, TL;DR: To summarize then, the computer software checking system and attitude is of the highest quality. There appears to be no process of gradually fooling oneself while degrading standards so characteristic of the Solid Rocket Booster or Space Shuttle Main Engine safety systems.