The Silver Bullet or Why Software Is Bad? - Tilted Forum Project Discussion Community

Blackthorn · 12-06-2004, 08:20 PM

This is a good article about why I will be employed for a very long time. Sofware reliability and how to improve it is the subject. In order to gain a full appreciation for the premise you should check out this linkie: No Silver Bullet. If you are at all connected to the world of software development you should have a look at this.

This is an abstract:

Quote:

There is something fundamentally wrong with the way we create software. This article describes a silver bullet solution to the problem of software reliability and productivity. The solution requires a fundamental change in the way we program our computers. I will argue that the main reason that software is so unreliable and so hard to produce has to do with a custom that is as old as the computer: the practice of using the algorithm as the basis of software construction. I will argue further that moving to a pure signal-based, synchronous software model will result in at least an order of magnitude improvement in both reliability and productivity.

MooseMan3000 · 12-06-2004, 09:04 PM

So what the article is saying is that... the brain is better than computers? Well, yeah. The argument that we a signal based computing system is ludicrous in terms of current hardware.

His main argument is that current, algorithm based programming doesn't work correctly in terms of timing; we have to wait for the processor to do its job. That argument holds true for signal based programming, too, unless we radically redesign our current hardware to, in essence, emulate our brains. If we could do that, don't you think we already would have? It's being worked on right now, but it's a long way from being implemented.

I agree that his intentions are noble, and if it was workable it would increase speed and reliability of computers; however, the logic seems circular to me. In order to increase effeciency, we must develop a more efficient means of computing, in order to develop a more efficient means of programming.

First, we have to have the hardware. Then this way of looking at the problem might work.

Phage · 12-06-2004, 11:41 PM

So far as I understand it, he is talking about how programming now is based around breaking a problem down into small components eventually reaching basic logical operations which when combined will return a desired result. This desired result is what we use a computer for; given exactly defined data it should return exact and correct responses in a hopefully timely manner.
The author hopes to break from this path of "Start, Think, Finish" into something more, where pre-built units converse freely and compute on their own to increase productivity, where threads will not sit idle waiting for processes to complete.

This is a noble ideal, but it requires many things. Each unit will require separate hardware to run each object's calculations, making the physical representation of this new breed of computer trying. How much time and processing muscle will be spent with the objects communicating with each other? How about one object being overloaded with requests from many other objects, resulting in universal slowdown? The author also submits that failure of an object will not always result in catastrophic failure; this would imply a certain amount of redundancy which unfortunately would become unwieldly amounts of bloat. How would you know if a section had failed without running the computations again and comparing them, and even then if there is a problem with the design of the object itself it would be useless. Suppose an object is talking to another object it is working with, and somehow decides that it's responses are suspect (or absent altogether); how could it continue?

Either you end up with the situation in our brains where there are many groupings that simply duplicate things done elsewhere (inefficient but reliable) or commonly used nodes which are overworked and if ever fail result in complete shutdown of all related operations.

As has already been noted, the implementation of such a system would be staggering in complexity, and the necessity of each object to act intelligently requires specialized hardware for any given task as well as wasted computing power and bloated code.

vox_rox · 12-07-2004, 02:33 PM

There is a simpler way. My computer Science instructor at University was, and still is, saddened a the state of software development. But he blames the consumers of software as much as those corporations coding the sad applications that we see today.

His thinking was that if everyone returned the software that didn't work as promised, or required patches and service packs just to work well and be secure, then the industry might well respond to by putting out well tested software instead of the late-tested betaware that we currently are exposed to.

Whether or not he's right is moot, but there are now dozens of cases where software is being returned, even after agreeing to the terms of use (which have been rendered as non-binding in several states by the way), and if we took some lead from this, maybe, he's right.

Still, it is sad that something that has become so intertwined into our daily lives is so badly prepared to be used by the same people who must use it.

Peace,

Pierre

Janey · 12-09-2004, 06:24 AM

Theoretically, An improvement in software development paradigms is fine. I however, would like to continue to have the same earning power that I currently have for atleast another 10 - 15 yrs (so i can retire, then get involved with the R&R) by that time i'll be in my 40's and not really needing/wanting to consult anymore. But during the meanwhile, I don't know any of my Univ. friends, even CAs or MD's who can pull in the hourly fees that I have or the salry that I managed at this stage of thier lives... So keep the bad code out there, keep selling those monstrous ERPS, and keep on re-designing business processes regardless of coporate inertia. muhha ha ha !!!!

vox_rox · 12-09-2004, 08:49 AM

Quote:

Originally Posted by Janey

Theoretically, An improvement in software development paradigms is fine. I however, would like to continue to have the same earning power that I currently have for atleast another 10 - 15 yrs (so i can retire, then get involved with the R&R) by that time i'll be in my 40's and not really needing/wanting to consult anymore. But during the meanwhile, I don't know any of my Univ. friends, even CAs or MD's who can pull in the hourly fees that I have or the salry that I managed at this stage of thier lives... So keep the bad code out there, keep selling those monstrous ERPS, and keep on re-designing business processes regardless of coporate inertia. muhha ha ha !!!!

Janey! You got your Avatar! Congrats!

As for the bad code, the truth is that there is an entire subculture that owes its existence to bad programming, and I know many people who consult in the IT biz that wouldn't have it any other way. However, there is a new breed out there who consult in Linux implementation only, and there you can find good code and a open-ended consulting world.

Still, it's all good until we're forced to live with bad code AND "trusted computing," but that's a rant for another day, and maybe even another board, like Tilted Paranoia!

Peace,

Pierre

12-07-2004, 02:33 PM	#4 (permalink)
vox_rox Psycho Location: Comfy Little Bungalow	There is a simpler way. My computer Science instructor at University was, and still is, saddened a the state of software development. But he blames the consumers of software as much as those corporations coding the sad applications that we see today. His thinking was that if everyone returned the software that didn't work as promised, or required patches and service packs just to work well and be secure, then the industry might well respond to by putting out well tested software instead of the late-tested betaware that we currently are exposed to. Whether or not he's right is moot, but there are now dozens of cases where software is being returned, even after agreeing to the terms of use (which have been rendered as non-binding in several states by the way), and if we took some lead from this, maybe, he's right. Still, it is sad that something that has become so intertwined into our daily lives is so badly prepared to be used by the same people who must use it. Peace, Pierre __________________ --- There is no such thing as strong coffee - only weak people. ---

12-06-2004, 09:04 PM	#2 (permalink)
MooseMan3000 wouldn't mind being a ninja. Location: Maine, the Other White State.	So what the article is saying is that... the brain is better than computers? Well, yeah. The argument that we a signal based computing system is ludicrous in terms of current hardware. His main argument is that current, algorithm based programming doesn't work correctly in terms of timing; we have to wait for the processor to do its job. That argument holds true for signal based programming, too, unless we radically redesign our current hardware to, in essence, emulate our brains. If we could do that, don't you think we already would have? It's being worked on right now, but it's a long way from being implemented. I agree that his intentions are noble, and if it was workable it would increase speed and reliability of computers; however, the logic seems circular to me. In order to increase effeciency, we must develop a more efficient means of computing, in order to develop a more efficient means of programming. First, we have to have the hardware. Then this way of looking at the problem might work.

12-06-2004, 11:41 PM	#3 (permalink)
Phage Insane	So far as I understand it, he is talking about how programming now is based around breaking a problem down into small components eventually reaching basic logical operations which when combined will return a desired result. This desired result is what we use a computer for; given exactly defined data it should return exact and correct responses in a hopefully timely manner. The author hopes to break from this path of "Start, Think, Finish" into something more, where pre-built units converse freely and compute on their own to increase productivity, where threads will not sit idle waiting for processes to complete. This is a noble ideal, but it requires many things. Each unit will require separate hardware to run each object's calculations, making the physical representation of this new breed of computer trying. How much time and processing muscle will be spent with the objects communicating with each other? How about one object being overloaded with requests from many other objects, resulting in universal slowdown? The author also submits that failure of an object will not always result in catastrophic failure; this would imply a certain amount of redundancy which unfortunately would become unwieldly amounts of bloat. How would you know if a section had failed without running the computations again and comparing them, and even then if there is a problem with the design of the object itself it would be useless. Suppose an object is talking to another object it is working with, and somehow decides that it's responses are suspect (or absent altogether); how could it continue? Either you end up with the situation in our brains where there are many groupings that simply duplicate things done elsewhere (inefficient but reliable) or commonly used nodes which are overworked and if ever fail result in complete shutdown of all related operations. As has already been noted, the implementation of such a system would be staggering in complexity, and the necessity of each object to act intelligently requires specialized hardware for any given task as well as wasted computing power and bloated code.

12-09-2004, 06:24 AM	#5 (permalink)
Janey Junkie Location: Toronto	Theoretically, An improvement in software development paradigms is fine. I however, would like to continue to have the same earning power that I currently have for atleast another 10 - 15 yrs (so i can retire, then get involved with the R&R) by that time i'll be in my 40's and not really needing/wanting to consult anymore. But during the meanwhile, I don't know any of my Univ. friends, even CAs or MD's who can pull in the hourly fees that I have or the salry that I managed at this stage of thier lives... So keep the bad code out there, keep selling those monstrous ERPS, and keep on re-designing business processes regardless of coporate inertia. muhha ha ha !!!!