Comment Re:Maybe it's needed, but who will develop it? (Score 1) 359
I have to agree the argument does seem flawed.
Meet the functional requirements of the task.
As soon as the task changes or becomes more complex, the functional requirements also change. This is a fundamental reason for things like bloat-ware. People make requests that change the functional requirements of large integrated apps.
This would seem more like an argument for the *NIX way of doing things which would be small programs with small tasks that could be chained together.
"Hmm I like this bridge but could you widen it for me?"
Robustness and long-term stability and security.
Stability and Security can never be gauranteed. A flaw is inevitable in any program. If that flaw is a fundamental flaw then the program would have to be rewritten.
"Oops, I think I went over the 2 ton limit you need to fix that bridge now."
Transparency to determine when changes are needed and that undesired functions are not being performed.
This seemed flawed in perspective. Typically if I talk about something being transparent I talk about it not being seen. And your typical user doesn't care to see the inner workings of a program. I only like being able to see the inner workings because I have a morbid facination with taking things apart sometimes. Hehe I love open-source not so much because I look at it in as much that it is there if I ever felt like looking at it.
"Do I really want to see what is underneath the bridge or look at it's supports?"
Ease and low cost of training for effective use.
Ease and low cost of maintenance.
These seem to be mutually exclusive to me. Either it's an application that is large and difficult to maintain, or it's a suite of small easily maintainable apps that you have to train the person to use each and how to effectively string them all together.
"Either cross the Golden Gate or go around the San Francisco Bay"
Ease of replacement.
I thought he just finished saying that he didn't want to replace these things for years.
"How many bridges that you know of are easy to replace and will last for years"
Long-term availability of individuals able to train, maintain, modify, determine need for changes, etc.
Look, your going to have to pay someone to do the maintaining and modifications. Unless the code is well documented or you have a large number of individuals that are familiar with the inner workings of the code it would take tremendous amounts of effort in order to just understand the algorythms used. Chances are if the new programmer didn't like the way it was written s/he will be more likely to rewrite the code.
"You have to train a civil engineer to be able to understand how the bridge was constructed, Then that civil engineer is going to have to assess the bridge and it's plans to find the discontinuities between the two. Then the civil engineer can do something to help you."
Meet the functional requirements of the task.
As soon as the task changes or becomes more complex, the functional requirements also change. This is a fundamental reason for things like bloat-ware. People make requests that change the functional requirements of large integrated apps.
This would seem more like an argument for the *NIX way of doing things which would be small programs with small tasks that could be chained together.
"Hmm I like this bridge but could you widen it for me?"
Robustness and long-term stability and security.
Stability and Security can never be gauranteed. A flaw is inevitable in any program. If that flaw is a fundamental flaw then the program would have to be rewritten.
"Oops, I think I went over the 2 ton limit you need to fix that bridge now."
Transparency to determine when changes are needed and that undesired functions are not being performed.
This seemed flawed in perspective. Typically if I talk about something being transparent I talk about it not being seen. And your typical user doesn't care to see the inner workings of a program. I only like being able to see the inner workings because I have a morbid facination with taking things apart sometimes. Hehe I love open-source not so much because I look at it in as much that it is there if I ever felt like looking at it.
"Do I really want to see what is underneath the bridge or look at it's supports?"
Ease and low cost of training for effective use.
Ease and low cost of maintenance.
These seem to be mutually exclusive to me. Either it's an application that is large and difficult to maintain, or it's a suite of small easily maintainable apps that you have to train the person to use each and how to effectively string them all together.
"Either cross the Golden Gate or go around the San Francisco Bay"
Ease of replacement.
I thought he just finished saying that he didn't want to replace these things for years.
"How many bridges that you know of are easy to replace and will last for years"
Long-term availability of individuals able to train, maintain, modify, determine need for changes, etc.
Look, your going to have to pay someone to do the maintaining and modifications. Unless the code is well documented or you have a large number of individuals that are familiar with the inner workings of the code it would take tremendous amounts of effort in order to just understand the algorythms used. Chances are if the new programmer didn't like the way it was written s/he will be more likely to rewrite the code.
"You have to train a civil engineer to be able to understand how the bridge was constructed, Then that civil engineer is going to have to assess the bridge and it's plans to find the discontinuities between the two. Then the civil engineer can do something to help you."
