Thanks for your reply. Certainly, I simplified the complexities of bridge building in my post. The primary point was that in engineering projects, such as these, there are always well-known requirements prior to completing the design. These requirements do not change after completion. Whereas in software, the requirements absolutely change (often by orders of magnitude) over time. For example, when graphics editing programs were being written 15 years ago no machine was even capable of accessing the amount of memory that single photo from high-end cameras can consume. The architectures designed and code written to support these architectures required certain limitations. This software will always behave poorly if the architecture of the original design is still being used with the newer graphics files. Failure of the code is to be expected under these types of changes.
In computers, change is one of the few constants. The machines of today have different processor architectures, memory availability, hard-drive space, networking speeds and protocols, etc. than the machines of the past and different still from the future machines that will come. The solutions that will be needed tomorrow simply cannot be implemented today because the machines of today lack the power that the machines of the future will have. This means that every system must, out of necessity, use shortcuts that will not be capable of providing the future's needs.
Then, on top of this problem, the software must run on so many different configurations of machines which implement protocols differently (and often incompletely) which fail in many different ways. The number of possible configurations is so great that it is literally impossible to test in all permutations which will be used to run the software.
The comment about there always being a solid surface if you dig deep enough was a tongue-in-cheek reference to a quandary that most programmers will recognize: everything you write depends upon the work of others who have written the OS, the device drivers, other currently running software and various protocols. If any one of these have errors or if the precise combinations of these produce errors then the code you write will become unstable despite your best efforts to keep them from becoming so. There is nothing completely stable underneath your code and the instabilities are often unknown and undiscoverable. Programmers, I'm certain, understood that but it should not be expected that it would come across to others and I apologize for not giving a little explanation in the original post.
I once designed a database system for a large government engineering organization. It's sole purpose was to track and maintain all engineering requirements and all the changes to the requirements throughout the engineering design process. It was always frustrating that the system I was developing had no requirements document and once it was written it changed every day. The delivered product is probably still being modified on a daily basis due to the groups inability to solidify their requirements. I guess I'm a little jealous that engineers get to have a finalized set of requirements while programmers are always having to change their products to match the new "latest thing."
I know engineering is serious and that engineers can go to prison for signing off on a design that fails, however, no engineer ever went to prison for designing a system that is proven to have met the original requirements. Programmers, on the other hand, are always being burned at the proverbial stake when some new device or software doesn't work with older devices and software that were written long before those new things were even dreamed of. They're also blamed when a malicious person finds chinks in the current implementations for the sole purpose of breaking the system. It's like blaming a bridge designer for a truckload of explosives damaging a bridge. (To use our previous comparison.)
There is never enough processing power, memory, storage or
As a software developer, I lie awake at night dreaming of only having to solve a problem as simple a bridge. It has only one use case: vehicles of a known weight with a known wheel surface traveling in predetermined paths at a predetermined rate of speed. Also, if you dig down deep enough on the Earth, there is always something solid to anchor the bridge. Then bridge developers have millions of existing examples which can be studied and reused.
In software, half the stuff people will do with it were unknown while it was being designed. It's placed on top of existing code (operating systems, existing architectures, outmoded designs) which deceases the stability of your own applications. Runs on systems with wildly different equipment from any test environment available with drivers written by corporate hacks which decrease your applications' performance. Then users use the application with many other applications which can interfere in numerous ways with the other applications while sucking up the required resources (memory, hard-drive space, etc.) your application needs. Which is not even mentioning the malicious attacks by those who only wish to wreak havoc on the systems. Then if any of the myriad of things running on the computer fail, everyone starts screaming that the developers are the problem.
The problem is that people expect the software to perform absolutely flawlessly while doing things that the developer never intended on a wide variety of equipment that cannot not be tested on or controlled by the developer. It's the world of continuous progress. No one changes the use cases of bridges after they are designed. No one every just tacks a few more lanes onto a bridge or decides to make the bridge into an airport runway after it was built. When was the last time someone re-commissioned a pedestrian bridge for railway traffic or built an additional level on the bridge for a shopping mall without significant studies to determine feasibility?
And yet if bridges were scrutinized the same way as software, people would be in an uproar about all the deaths that are only possible because of the bridges: people jump off of them, cars crash over the guard rails, tornadoes and hurricanes wipe them out, and if they are not maintained properly they eventually fall to the ground under their own weight. Books could be filled with the death stories of people killed by bridges. Everyone sees how silly it is to blame a bridge designer when people are not using or maintaining the bridge in the way intended.
This is not to say that there is not badly designed software out there or that much of it couldn't be done better. However, people need to understand that to have completely bullet-proof software would require studying all possible use cases, locking all features and hardware, then designing a system that will perform only those features and nothing else ad infinitum. Of course, that's exactly what a group of mindless, uncreative government regulators will do. I'd rather have innovation and patches and the largest number of technical resources and methodologies available for the problem.
The core problem is that solutions are being locked up by patents and business methodologies rater that allowing all the code to be shared and reused by everyone allowing everyone to benefit from new applications of previous solutions. I don't really expect Oracle to agree since they make a tremendous amount of money from closed code and patents and would really love to kill all new entry into the market. Of course, they don't really believe in making code that works without patching, either, or they would no longer be patching their own supposedly well-designed and executed flagship product. It's just rhetoric and business as usual.
Many people simply use a DVR provided by their cable company. So it's pretty easy for the cable company to force everyone to upgrade to their new box (the inability to change channels could even work with a non-DVR cable box.) The cable company could then make a chunk of change off the skipping fees.
Likewise, Tivo could make some money from the skipping fees and could easily do a software update to add the disfeature to their boxes. If those two companies agree to do it then the consumers will be stuck with the system. With Tivo's patents and cable's ownership of distribution there is really no way for others to offer an alternative.
If MythTV ever gains enough ground, I'm sure they'll be sued out of existence. The media industry has so few players that we are all stuck with whaterver they give us and they have no need to compete or try to give the consumer what they want. How many people want those logos in the corner of the screen? Or the animated advertisements that are popping up on the bottom of the screen? Or all the shows tooled completely around some product placement scheme? The people will continue to buy the entertainment, no matter how bad they get because we have no competitive sources.
Of course, the real reason Tivo wants to have viewers identified by RFID is so they can sell the data to the television networks for advertising tracking. They already do this with the their data. Remember the Janet Jackson superbowl incident was said by Tivo to be the most rewinds of any event because they track everything their users watch/record/rewind. The obvious "holy grail" is to track it to an individual person, not just to the box.
We Need to Start a Programmers Guild
on
Bad Day To Be Sony
·
· Score: 2, Insightful
As a programmer, I have felt for quite some time that we need to have a "Programmers Guild" similar to the guilds of Medieval times. In the guilds of yore, the professionals of a craft actively monitored the products of other craftsmen and would punish/train/certify those who performed the craft badly. It has always bothered me that the most inept programmers continue to find work in our industry. Sadly, the only people in the industry who seem capable of evaluating a programmer's ability is other good programmers. The people responsible for this crappy code should simply not be allowed to work as programmers ever again.
Instead these people will have a resume that proudly proclaims, "Worked to create high quality software with millions of users for Sony," and the managers they interview with will be quite impressed and put them in charge of more programming projects.
For the sake of our craft, we desperately need to create a software programmers' guild.
Slashdot Mirror
Now all I need is a way to automatically blacklist all of the "experts" and the number of opinionated blowhards who contact me will decrease.
Thanks for your reply. Certainly, I simplified the complexities of bridge building in my post. The primary point was that in engineering projects, such as these, there are always well-known requirements prior to completing the design. These requirements do not change after completion. Whereas in software, the requirements absolutely change (often by orders of magnitude) over time. For example, when graphics editing programs were being written 15 years ago no machine was even capable of accessing the amount of memory that single photo from high-end cameras can consume. The architectures designed and code written to support these architectures required certain limitations. This software will always behave poorly if the architecture of the original design is still being used with the newer graphics files. Failure of the code is to be expected under these types of changes.
In computers, change is one of the few constants. The machines of today have different processor architectures, memory availability, hard-drive space, networking speeds and protocols, etc. than the machines of the past and different still from the future machines that will come. The solutions that will be needed tomorrow simply cannot be implemented today because the machines of today lack the power that the machines of the future will have. This means that every system must, out of necessity, use shortcuts that will not be capable of providing the future's needs.
Then, on top of this problem, the software must run on so many different configurations of machines which implement protocols differently (and often incompletely) which fail in many different ways. The number of possible configurations is so great that it is literally impossible to test in all permutations which will be used to run the software.
The comment about there always being a solid surface if you dig deep enough was a tongue-in-cheek reference to a quandary that most programmers will recognize: everything you write depends upon the work of others who have written the OS, the device drivers, other currently running software and various protocols. If any one of these have errors or if the precise combinations of these produce errors then the code you write will become unstable despite your best efforts to keep them from becoming so. There is nothing completely stable underneath your code and the instabilities are often unknown and undiscoverable. Programmers, I'm certain, understood that but it should not be expected that it would come across to others and I apologize for not giving a little explanation in the original post.
I once designed a database system for a large government engineering organization. It's sole purpose was to track and maintain all engineering requirements and all the changes to the requirements throughout the engineering design process. It was always frustrating that the system I was developing had no requirements document and once it was written it changed every day. The delivered product is probably still being modified on a daily basis due to the groups inability to solidify their requirements. I guess I'm a little jealous that engineers get to have a finalized set of requirements while programmers are always having to change their products to match the new "latest thing."
I know engineering is serious and that engineers can go to prison for signing off on a design that fails, however, no engineer ever went to prison for designing a system that is proven to have met the original requirements. Programmers, on the other hand, are always being burned at the proverbial stake when some new device or software doesn't work with older devices and software that were written long before those new things were even dreamed of. They're also blamed when a malicious person finds chinks in the current implementations for the sole purpose of breaking the system. It's like blaming a bridge designer for a truckload of explosives damaging a bridge. (To use our previous comparison.)
There is never enough processing power, memory, storage or
As a software developer, I lie awake at night dreaming of only having to solve a problem as simple a bridge. It has only one use case: vehicles of a known weight with a known wheel surface traveling in predetermined paths at a predetermined rate of speed. Also, if you dig down deep enough on the Earth, there is always something solid to anchor the bridge. Then bridge developers have millions of existing examples which can be studied and reused.
In software, half the stuff people will do with it were unknown while it was being designed. It's placed on top of existing code (operating systems, existing architectures, outmoded designs) which deceases the stability of your own applications. Runs on systems with wildly different equipment from any test environment available with drivers written by corporate hacks which decrease your applications' performance. Then users use the application with many other applications which can interfere in numerous ways with the other applications while sucking up the required resources (memory, hard-drive space, etc.) your application needs. Which is not even mentioning the malicious attacks by those who only wish to wreak havoc on the systems. Then if any of the myriad of things running on the computer fail, everyone starts screaming that the developers are the problem.
The problem is that people expect the software to perform absolutely flawlessly while doing things that the developer never intended on a wide variety of equipment that cannot not be tested on or controlled by the developer. It's the world of continuous progress. No one changes the use cases of bridges after they are designed. No one every just tacks a few more lanes onto a bridge or decides to make the bridge into an airport runway after it was built. When was the last time someone re-commissioned a pedestrian bridge for railway traffic or built an additional level on the bridge for a shopping mall without significant studies to determine feasibility?
And yet if bridges were scrutinized the same way as software, people would be in an uproar about all the deaths that are only possible because of the bridges: people jump off of them, cars crash over the guard rails, tornadoes and hurricanes wipe them out, and if they are not maintained properly they eventually fall to the ground under their own weight. Books could be filled with the death stories of people killed by bridges. Everyone sees how silly it is to blame a bridge designer when people are not using or maintaining the bridge in the way intended.
This is not to say that there is not badly designed software out there or that much of it couldn't be done better. However, people need to understand that to have completely bullet-proof software would require studying all possible use cases, locking all features and hardware, then designing a system that will perform only those features and nothing else ad infinitum. Of course, that's exactly what a group of mindless, uncreative government regulators will do. I'd rather have innovation and patches and the largest number of technical resources and methodologies available for the problem.
The core problem is that solutions are being locked up by patents and business methodologies rater that allowing all the code to be shared and reused by everyone allowing everyone to benefit from new applications of previous solutions. I don't really expect Oracle to agree since they make a tremendous amount of money from closed code and patents and would really love to kill all new entry into the market. Of course, they don't really believe in making code that works without patching, either, or they would no longer be patching their own supposedly well-designed and executed flagship product. It's just rhetoric and business as usual.
Many people simply use a DVR provided by their cable company. So it's pretty easy for the cable company to force everyone to upgrade to their new box (the inability to change channels could even work with a non-DVR cable box.) The cable company could then make a chunk of change off the skipping fees.
Likewise, Tivo could make some money from the skipping fees and could easily do a software update to add the disfeature to their boxes. If those two companies agree to do it then the consumers will be stuck with the system. With Tivo's patents and cable's ownership of distribution there is really no way for others to offer an alternative.
If MythTV ever gains enough ground, I'm sure they'll be sued out of existence. The media industry has so few players that we are all stuck with whaterver they give us and they have no need to compete or try to give the consumer what they want. How many people want those logos in the corner of the screen? Or the animated advertisements that are popping up on the bottom of the screen? Or all the shows tooled completely around some product placement scheme? The people will continue to buy the entertainment, no matter how bad they get because we have no competitive sources.
People who are capable of changing tasks quickly enjoy playing videogames.
Of course, the real reason Tivo wants to have viewers identified by RFID is so they can sell the data to the television networks for advertising tracking. They already do this with the their data. Remember the Janet Jackson superbowl incident was said by Tivo to be the most rewinds of any event because they track everything their users watch/record/rewind. The obvious "holy grail" is to track it to an individual person, not just to the box.
As a programmer, I have felt for quite some time that we need to have a "Programmers Guild" similar to the guilds of Medieval times. In the guilds of yore, the professionals of a craft actively monitored the products of other craftsmen and would punish/train/certify those who performed the craft badly. It has always bothered me that the most inept programmers continue to find work in our industry. Sadly, the only people in the industry who seem capable of evaluating a programmer's ability is other good programmers. The people responsible for this crappy code should simply not be allowed to work as programmers ever again. Instead these people will have a resume that proudly proclaims, "Worked to create high quality software with millions of users for Sony," and the managers they interview with will be quite impressed and put them in charge of more programming projects. For the sake of our craft, we desperately need to create a software programmers' guild.