Your code is far more chaff than wheat
-
Did they look at only COBOL? :confused:
-
I can believe it. For every one line of code that has actual business value, I find myself writing an awful lot of lines for things like exception handling, null checking, error logging, thread locking, bounds checking, etc... None of which has any business value beyond just getting the damn thing to run without problems.
-
I can believe it. For every one line of code that has actual business value, I find myself writing an awful lot of lines for things like exception handling, null checking, error logging, thread locking, bounds checking, etc... None of which has any business value beyond just getting the damn thing to run without problems.
I'd say all of that is required to provide the required functionality.
-
I'd say all of that is required to provide the required functionality.
Not entirely. Thread locking is only needed if you have contention problems. Logging is only necessary if you need to go look at log files. Bounds checking is only necessary when someone tries to bypass UI validation, etc... All of these are good things to have. I put all of them into my code. But the only thing they do is relieve IT headaches. They don't sell more widgets.
-
Not entirely. Thread locking is only needed if you have contention problems. Logging is only necessary if you need to go look at log files. Bounds checking is only necessary when someone tries to bypass UI validation, etc... All of these are good things to have. I put all of them into my code. But the only thing they do is relieve IT headaches. They don't sell more widgets.
Vark111 wrote:
They don't sell more widgets
Sure they do. Uptime is directly related to sales.
-
Do you think car designers have magazines with articles with "how airbags add weight and reduce petrol efficiency"?
-
Did they look at only COBOL? :confused:
Almost as bad - I think they looked at Java (and included all the XML configuration files)
TTFN - Kent
-
-
I think it is too early to jump to the conclusion that most code are 'useless' as chaff. If we are to throw away the 'chaff' and just submit the 'wheat' to client, it would be a disaster. OOP introduce "redundency"　because we want to system to be scalable and extensible. We are living in an imperfect world , our main objective is to provide convenience to users and other developers, rather than giving values to every lines of code.
-
Not entirely. Thread locking is only needed if you have contention problems. Logging is only necessary if you need to go look at log files. Bounds checking is only necessary when someone tries to bypass UI validation, etc... All of these are good things to have. I put all of them into my code. But the only thing they do is relieve IT headaches. They don't sell more widgets.
You only need an airbag in an accident, that is true. Logging is not just required if someone wants to look at the logs; it is required to be able to track what the application is doing. Bounds checking is not just for people trying to bypass, but also to reduce accidental errors. The fact that it is not explicitly mentioned as something that you get paid for doesn't mean that it has no value.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
You only need an airbag in an accident, that is true. Logging is not just required if someone wants to look at the logs; it is required to be able to track what the application is doing. Bounds checking is not just for people trying to bypass, but also to reduce accidental errors. The fact that it is not explicitly mentioned as something that you get paid for doesn't mean that it has no value.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
I don't disagree with anything you said. The point I guess I'm trying to make is that 15 years ago, when I was writing VB6 apps before I really should have been, I did none of those things. No null checking, no bounds checking, no logging, etc... Those apps were an abomination from my (current) perspective, but did they provide business value back then? Unquestionably. If I were to grab one of those apps today and add all those things back in - exception handling, null checking, logging, etc... Would the business value of those apps increase? In my opinion, that's questionable. If the app used to crash twice a day because of those problems, then adding those checks and balances in probably does increase business value. But if that app was only crashing once a year?
-
I don't disagree with anything you said. The point I guess I'm trying to make is that 15 years ago, when I was writing VB6 apps before I really should have been, I did none of those things. No null checking, no bounds checking, no logging, etc... Those apps were an abomination from my (current) perspective, but did they provide business value back then? Unquestionably. If I were to grab one of those apps today and add all those things back in - exception handling, null checking, logging, etc... Would the business value of those apps increase? In my opinion, that's questionable. If the app used to crash twice a day because of those problems, then adding those checks and balances in probably does increase business value. But if that app was only crashing once a year?
Vark111 wrote:
But if that app was only crashing once a year?
A few years ago, cars came without said airbag. You don't even need to be able to lock the car to provide the basic functionality. Does it matter if it crashes once a year? Well, no, I hear that cars are called back all the time. As long as it isn't my car, all is great :-\
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]