If you are not an US citizen, but live in a country that falls within the bounds of the visa waiver programme, then "Are you a terrorist?" is indeed one of the questions you have to answer on the little green form they issue you on the plane.
I believe the actual question is "Are you, or have you ever been a member of a terrorist organisation?", of course with a helpful footnote informing you that if you answer yes, you may be denied entry to the USA.
As Kyoto sets up an international trading system in "emission rights", the signatories are not obliged to reach hard emission targets: They can opt to pay cash instead. I would have assumed that this free-market approach to environmental policy has appeal to economic conservatives, but apparently they are too busy sticking their heads in the sand.
The argument that Kyoto is ruinous for the economy makes very little sense. Apart from the damage that will be done by unchecked global warming, it makes both economic and political sense to reduce the consumption of such fuels. It would still make sense, even if there was no climate change connected to it at all. We are seeing the end of cheap oil supplies, and over the next decades the more energy-efficient (and self-sufficient) economies will have an important competitive advantage.
As for the "failing euro", what failing euro? The currency that has taken a steep plunge in recent times is the US dollar. Admittedly less so because of any fundamental problems with the US economy, than because of the financial market distrust of the haemorrhaging US debt -- and the apparent total indifference of the debtor concerning his ability to finance (let alone repay) his debt to the rest of the world.
Don't forget that it was not until 1958 that there was an international agreement on how long a feet is. Before that, American, British and Canadian measurements were slightly different, just to make life more difficult for the engineers.
As for "no mention" being made of the metric system, even in the USA this would be very difficult when talking about standards, because the inch is defined as 24.5 millimeter, and the pound is defined as 0.45359237 kilogram.
In my opinion, an important, and possibly essential, step towards a good design strategy is co-design of the process and the software. They are too deeply interlinked to be separated.
If you design the process first and the software later, you probably arrive at a process that is quite difficult to automate, and inefficient as well. When people do things manually, they simply do them differently than they (should) do if they have software to support them.
If you design and write the software first and expect people to adapt the process to it, you are probably producing something that doesn't fit a real-world process, and the users will curse you.
But if you design both together, the users will supply the process knowledge, and a good software designer is also a good process analist. Bring together the know-how will make both the process and the software better, because the software designer will understand the process and the process will be more suitable for efficient automation.
I admit that it is sometimes hard to do. I do know heads of software teams who say that they should not be expected to understand the process, let alone participate in its design; and I also know R&D leaders who are reluctant to discuss processes with (hardware or software) engineers until they have been fine-tuned.
But certainly, one of the most frequent reasons for bad software design is lack of contact between users and designers. When I am told that the hardware is made in Japan, the software is written in the USA and the applications are developed in Germany (and that is a real-world example, actually...) I begin to develop serious doubts! I am actually opposed (if they work in the same company) to the common practice of putting software developers in a separate administrative department.
As for quality control, I am not familiar with CMM but I have seen enough of quality systems to confidently say that any quality system that is not supported and understood by the people who actually do the work, is completely worthless. "Quality must be built into a system, it cannot be inspected into it." Unfortunately QA is too often based on the bureaucratic instinct that says that any organisatorial problem can be solved by introducing a new form for people to fill in. (The amount of regulation and legislation that is based on this single principle, is amazing!)
I agree that free speech entitles you to spend your own money to publish your views. However, this is not quite what political campaign financing does. (And the same can be said for the general lobby and PR machinery.)
If the CEO of a large oil company wants to spend his money or his company's money to make public that "Hi, I am the CEO of Exxon Mobil and I support candidate X for president because I think it would be good for the economy and my company if he gets elected.", then that would be perfectly acceptable. It would be fair to the voter, the industry, and the candidate. But it is not what happens in reality.
What happens is that funds are collected either to fund some political campaign directly, or to finance American Citizens In Support Of Future Economic Growth, or whatever those silly fronts are called. The public is not informed by public free speech, it is misled by secretively arranged and expensive propaganda. And this is not limited to election campaigns: Companies like Exxon support dozens of pressure groups with misleading names such as "Committee for a Constructive Tomorrow" in an attempt to bias government policy.
Last but not least, who do you want to pay your politicians? They are the people's employees: Voters choose them, entrust them with power, pay their wages, provide them with offices. I am pretty certain that, for example, Sun would take a dim view of any employee who would accept money equivalent to several times his wages from Microsoft. Yet voters are asked to tolerate that the people they chose to work for them, are completely dependent on large amounts of cash supplied by third parties. This is absurd.
Let me put it this way -- I have seen software in which relying on the default value supplied by the programmer for an input, was absolutely guarantueed to cause physical damage worth thousands of US$.
Called me narrow-minded, call me a part-time programmer, but I'm not joking.
I am not entirely convinced that unwillingness of customers to pay for QA is really the problem, because I happen to work in an industry that is QA sensitive. We would indeed be willing to pay more for robust software, if only because it would finally be much more cost-effective for us. And we often have to perform our own internal validation of it anyway (although this is often quite superficial) so it saves time if it is right from start. Besides, adherence to quality and data security standards often is a big selling point for our vendors.
Does this mean that we actually get better software? I don't think so. On the contrary; I automatically suspect any vendor who solemnly claims that his software is completed QA'd and validated. The fundamental reason is the amateurism that prevails at far too many of our suppliers -- indeed attributable to bad design, bad management of development, and minimal investment. The admitted reality is that if you want really robust system automation, you use PLC control, not PC software.
As for open source software, I think you have to consider that if there is nobody willing to take responsibility for it, many industrial customers will be unwilling to use or endorse it. A maddingly expensive system is often preferred over one that is basically free and may be just as good or even better, because the expensive system has someone behind it to service it and say that it is validated. Perhaps that doesn't make much sense, but it is a reality.
Someone has to take responsibiluty. That's why RedHat has often been crucial to get Linux 'in'.
An additional comment: One reason I like to work in Java is that some of my software is single-user software in the most literal sense: There is one person using them, besides myself.
Writing 15,000 lines of fairly complicated code for a single user, or four times as much for a dozen users, can make sense; although probably most software companies would disagree. However, I naturally want to do it in a language that offers rich libraries and is easy to troubleshoot. Java fits the bill almost perfectly; in many other languages I would be spending twice as much time on the same project.
I can perfectly understand that people who write application servers for eBay, or office applications for an user base of millions, feel that Java is not the best choice for it. However, the economics of that are entirely different.
I think that if you have to write an application that is too complicated or demanding for a script language, but also need to keep the investment in time and resources down, Java, mixed with a little C++ where necessary, is close to ideal. Before Java, I used a mix of Tcl/Tk and C++, and that was OK, but not great.
I think much of the fury against poor Bill Thompson is unfair. Yes, I agree that it is, in today's environment, very hard, borderline impossible, top write completely error-free software. However, a substantial quality improvement is very well possible.
I also suspect that especially for the Americans among us, talking about 'liability' invokes the spectre of enormous fines and damage payments, capable of shutting down activity and bankrupting companies. Obviously, that is not the way to go.
However, I fully support him if he says that programmers should take responsibility for the quality of their products, and that quality should be very much improved. I have three good reasons for that:
I spend a surprisingly large amount of time troubleshooting the products of others, then trying to convince them that (1) the problem is real, (2) the problem should be cured, and (3) we should not have to pay them for solving their own errors. I end up doing a lot of quality testing and writing reports for others, that they should have generated internally.
Whenever I or my colleagues have to select an external software contractor for a project, often mission-critical and involving a big expenditure of money, we can too often only go by instinct and pray that they know what they are doing and will assign capable developers to the project. I think that at the current state of the industry, we have a 50/50 chance. If the contractor returns a hopeless mess, we have lost valuable time and money; and it is usually too late to do anything about it.
Last but not least, I very well have to take responsibility for the quality of my products. Much of my installed user base can be found within 100ft of my office, and user feedback is pretty direct. (I admit that is a luxury few of us have.) I don't see why others should not take responsibility.
People like to shoot at Microsoft, because they are big and we all have some reason to complain about them, but let's face reality: Looking at the industry as a whole, they are well above average. People like to smirk when MS announces delays and trouble with a new OS; but considering the failure rate of large software projects --- not to mention all the expensive systems that are delivered but turn out to be useless --- they have little reason to.
We have never encountered many problems with JNI interfaces, perhaps simply because we choose to keep this kind of interface as simple as possible and do not actually do it that often. Certainly I find it much less troublesome and time-consuming to generate and test a JNI interface than most others; although that may be largely down to experience.
I remember that we once had one server-side JNI call we had enormous trouble with, making us try all kinds of ways around it, including testing three or four different VMs. Some were indeed more stable than others, but we finally discovered that it was our own fault because our JNI implementation had a bug in its memory management. We fixed that and the system became capable of running for indefinite time (i.e. until the hardware fails or we have a power cut) without human intervention, one any Sun JRE after 1.3. Actually, I recently saw that it still has an UTF string release bug in it, but apparently this doesn't cause any trouble (yet).
Sometimes the system architecture calls for layering multiple interfaces -- as in PL/SQL calling Java calling C++ -- and that can be tricky, because you have to respect all the different 'boundary conditions'. But on the whole JNI is much better than some other interfacing technologies I have seen; especially the ones designed for specific systems.
I have been using Java for a long time, for server software, server-side methods and client-side applications. In general, through not always, interacting with databases. I have also written C++ code, both for similar purposes and for hardware control.
My experience is that in a well-written Java application, the performance of the JVM is usually not the real cause of performance bottlenecks that can be felt by the user. Design errors can make Java code slow; it may be a relatively "easy" language but the programmer still has to understand very well what he or she is doing, and seemingly unimportant choices can have serious performance impact -- just as in C++.
Fortunately, understanding the system is much easier in Java than, in say, Visual C++ (to mention just one abomination from the deep.) I suspect that on average Java code contains fewer blunders with a serious performance impact than C++ code.
Certainly, for the really high-speed parts of the code and for specialized purposes I too would still recommend to use C++, but for 95% of all code there is no reason not to write it in Java. And it is fairly simple to integrate C++ code in Java.
I harbour a suspicion that programmers who insist on writing all code in C++ or even C because they think that it will be faster, are largely the same people who insist on writing labyrinthine, unstable and unmaintainable code because they think that is faster. As you may suspect, I don't have a high opinion of programmers in general: I think that in general, only a third of professional programmers can be called competent (enough) to safely handle tools such as C++. The rest should be kept in to a sandbox.
And besides, the majority of infuriatingly slow applications that I have seen were not written in Java: More typically these are the work of naive Visual C++ and Basic programmers, the kind of people who recalculate the layout of the entire screen when they need to change the display of a variable, or copy the content of an entire database to memory on start-up.
A caveat, however: Java performance can depend enormously on how your system is set up. For example, the way the on-access scan of McAfee antivirus handles the Java JRE and other libraries is a bloody disgrace and results in painfully and unacceptably long startup times. But that is hardly Sun's fault. (Note for the next job interview: Ask what virus scanner they use.)
I admit that relying on garbage collection can be unnerving for the C and C++ programmer. I think I was nervous about not explictly de-allocating memory for the first two years or so; then I got used to it. (And, despite finally acquiring Java habits, I do not forget to de-allocate in C++ code. If anything, I am more accurate in it than I used to be.)
Ironically -- and this should serve as another caveat -- the biggest memory leak I ever created was in Java, not in C++. What I had overlooked is that the GC will not get rid of memory if a reference to it has been passed to a dialog; and I had forgotten to dispose of the dialog, which (very indirectly) controlled the display of a large data set.
Your argument appears to be that software programmers should be allowed to indulge in practices known to be unsafe, only because they happen to work on the particular platform that they happen to be developing on.
Frankly, I don't even see why a software supplier should allow his developers to get away with that. Portability and maintainability are basic real-world criteria, not luxury features. They determine the value, not only of the application, but of the code and its potential use in future releases. Any supplier with business sense should ensure that the upgrades necessary to accomodate future software environments are (1) as small as possible and (2) well-documented and localised.
Actually, for once people should be allowed to blame Microsoft for their problems. Far too much modern software has badly documented OS depencies scattered all over it, instead of grouped in tool classes with clearly defined interfaces. I know at least one software team (and it was not even working for an IT company) that decided to write its own software library, re-implementing even the basics instead of relying on Microsoftisms, and found that this not only eliminated undesirable OS dependencies, but resulted in substantial gains in both performance and stability.
Progammers should be realistic about the environment in which their code has to live, and write their code defensively. I would call a null pointer read that does not cause problems with a given Kernel implementation, a bug. It is just fortunate that it has not been triggered yet, but it still is a bug.
It has to be admitted that the software environment in which an application has to run can be spectacularly bad, especially in large companies that are hostage to the tyranny of their IT departments. And of course, sometimes the environment does change in ways that would badly affect any code. But the excuse should not be invoked more often than is strictly necessary.
Actually, consumer software is not so bad, if you compare it to the software that is supplied with scientific instruments and research tools. This is a relatively small market, and its buyers have put up with software quality standards that are below par -- in part because so few of them are programmers themselves.
Even at the high end of the market -- and that means upwards from 200,000 euros list price -- you will easily find instruments that fail because communication protocols have not been implemented properly, there are substantial memory or resource leaks, or methods have *never* been tested under remotely realistic conditions. It is fairly common to encounter software there that has incorrect storage of logs, writes data in absolutely impractical formats, or cannot re-export data (that it has internally!) if the first export attempt failed. If you study it more closely, you will find complicated DLLs or ActiveX interfaces, designed and used to control expensive instruments, that are undocumented or incorrectely documented. And as for the design of most user interfaces, it doesn't bear mentioning.
And you would be mistaken to assume that the supplier of an instrument that is worth a house (or several houses) takes liability for bugs in its software. In fact, it is not impossible that they will actually charge the buyer for correcting their bugs.
The good news: Most of these suppliers are glad to receive customer feedback...
Slashdot Mirror
If you are not an US citizen, but live in a country that falls within the bounds of the visa waiver programme, then "Are you a terrorist?" is indeed one of the questions you have to answer on the little green form they issue you on the plane.
I believe the actual question is "Are you, or have you ever been a member of a terrorist organisation?", of course with a helpful footnote informing you that if you answer yes, you may be denied entry to the USA.
As Kyoto sets up an international trading system in "emission rights", the signatories are not obliged to reach hard emission targets: They can opt to pay cash instead. I would have assumed that this free-market approach to environmental policy has appeal to economic conservatives, but apparently they are too busy sticking their heads in the sand.
The argument that Kyoto is ruinous for the economy makes very little sense. Apart from the damage that will be done by unchecked global warming, it makes both economic and political sense to reduce the consumption of such fuels. It would still make sense, even if there was no climate change connected to it at all. We are seeing the end of cheap oil supplies, and over the next decades the more energy-efficient (and self-sufficient) economies will have an important competitive advantage.
As for the "failing euro", what failing euro? The currency that has taken a steep plunge in recent times is the US dollar. Admittedly less so because of any fundamental problems with the US economy, than because of the financial market distrust of the haemorrhaging US debt -- and the apparent total indifference of the debtor concerning his ability to finance (let alone repay) his debt to the rest of the world.
Don't forget that it was not until 1958 that there was an international agreement on how long a feet is. Before that, American, British and Canadian measurements were slightly different, just to make life more difficult for the engineers.
As for "no mention" being made of the metric system, even in the USA this would be very difficult when talking about standards, because the inch is defined as 24.5 millimeter, and the pound is defined as 0.45359237 kilogram.
In my opinion, an important, and possibly essential, step towards a good design strategy is co-design of the process and the software. They are too deeply interlinked to be separated.
I admit that it is sometimes hard to do. I do know heads of software teams who say that they should not be expected to understand the process, let alone participate in its design; and I also know R&D leaders who are reluctant to discuss processes with (hardware or software) engineers until they have been fine-tuned.
But certainly, one of the most frequent reasons for bad software design is lack of contact between users and designers. When I am told that the hardware is made in Japan, the software is written in the USA and the applications are developed in Germany (and that is a real-world example, actually...) I begin to develop serious doubts! I am actually opposed (if they work in the same company) to the common practice of putting software developers in a separate administrative department.
As for quality control, I am not familiar with CMM but I have seen enough of quality systems to confidently say that any quality system that is not supported and understood by the people who actually do the work, is completely worthless. "Quality must be built into a system, it cannot be inspected into it." Unfortunately QA is too often based on the bureaucratic instinct that says that any organisatorial problem can be solved by introducing a new form for people to fill in. (The amount of regulation and legislation that is based on this single principle, is amazing!)
I agree that free speech entitles you to spend your own money to publish your views. However, this is not quite what political campaign financing does. (And the same can be said for the general lobby and PR machinery.)
If the CEO of a large oil company wants to spend his money or his company's money to make public that "Hi, I am the CEO of Exxon Mobil and I support candidate X for president because I think it would be good for the economy and my company if he gets elected.", then that would be perfectly acceptable. It would be fair to the voter, the industry, and the candidate. But it is not what happens in reality.
What happens is that funds are collected either to fund some political campaign directly, or to finance American Citizens In Support Of Future Economic Growth, or whatever those silly fronts are called. The public is not informed by public free speech, it is misled by secretively arranged and expensive propaganda. And this is not limited to election campaigns: Companies like Exxon support dozens of pressure groups with misleading names such as "Committee for a Constructive Tomorrow" in an attempt to bias government policy.
Last but not least, who do you want to pay your politicians? They are the people's employees: Voters choose them, entrust them with power, pay their wages, provide them with offices. I am pretty certain that, for example, Sun would take a dim view of any employee who would accept money equivalent to several times his wages from Microsoft. Yet voters are asked to tolerate that the people they chose to work for them, are completely dependent on large amounts of cash supplied by third parties. This is absurd.
Let me put it this way -- I have seen software in which relying on the default value supplied by the programmer for an input, was absolutely guarantueed to cause physical damage worth thousands of US$.
Called me narrow-minded, call me a part-time programmer, but I'm not joking.
I am not entirely convinced that unwillingness of customers to pay for QA is really the problem, because I happen to work in an industry that is QA sensitive. We would indeed be willing to pay more for robust software, if only because it would finally be much more cost-effective for us. And we often have to perform our own internal validation of it anyway (although this is often quite superficial) so it saves time if it is right from start. Besides, adherence to quality and data security standards often is a big selling point for our vendors.
Does this mean that we actually get better software? I don't think so. On the contrary; I automatically suspect any vendor who solemnly claims that his software is completed QA'd and validated. The fundamental reason is the amateurism that prevails at far too many of our suppliers -- indeed attributable to bad design, bad management of development, and minimal investment. The admitted reality is that if you want really robust system automation, you use PLC control, not PC software.
As for open source software, I think you have to consider that if there is nobody willing to take responsibility for it, many industrial customers will be unwilling to use or endorse it. A maddingly expensive system is often preferred over one that is basically free and may be just as good or even better, because the expensive system has someone behind it to service it and say that it is validated. Perhaps that doesn't make much sense, but it is a reality.
Someone has to take responsibiluty. That's why RedHat has often been crucial to get Linux 'in'.
An additional comment: One reason I like to work in Java is that some of my software is single-user software in the most literal sense: There is one person using them, besides myself.
Writing 15,000 lines of fairly complicated code for a single user, or four times as much for a dozen users, can make sense; although probably most software companies would disagree. However, I naturally want to do it in a language that offers rich libraries and is easy to troubleshoot. Java fits the bill almost perfectly; in many other languages I would be spending twice as much time on the same project.
I can perfectly understand that people who write application servers for eBay, or office applications for an user base of millions, feel that Java is not the best choice for it. However, the economics of that are entirely different.
I think that if you have to write an application that is too complicated or demanding for a script language, but also need to keep the investment in time and resources down, Java, mixed with a little C++ where necessary, is close to ideal. Before Java, I used a mix of Tcl/Tk and C++, and that was OK, but not great.
I think much of the fury against poor Bill Thompson is unfair. Yes, I agree that it is, in today's environment, very hard, borderline impossible, top write completely error-free software. However, a substantial quality improvement is very well possible.
I also suspect that especially for the Americans among us, talking about 'liability' invokes the spectre of enormous fines and damage payments, capable of shutting down activity and bankrupting companies. Obviously, that is not the way to go.
However, I fully support him if he says that programmers should take responsibility for the quality of their products, and that quality should be very much improved. I have three good reasons for that:
People like to shoot at Microsoft, because they are big and we all have some reason to complain about them, but let's face reality: Looking at the industry as a whole, they are well above average. People like to smirk when MS announces delays and trouble with a new OS; but considering the failure rate of large software projects --- not to mention all the expensive systems that are delivered but turn out to be useless --- they have little reason to.
We have never encountered many problems with JNI interfaces, perhaps simply because we choose to keep this kind of interface as simple as possible and do not actually do it that often. Certainly I find it much less troublesome and time-consuming to generate and test a JNI interface than most others; although that may be largely down to experience.
I remember that we once had one server-side JNI call we had enormous trouble with, making us try all kinds of ways around it, including testing three or four different VMs. Some were indeed more stable than others, but we finally discovered that it was our own fault because our JNI implementation had a bug in its memory management. We fixed that and the system became capable of running for indefinite time (i.e. until the hardware fails or we have a power cut) without human intervention, one any Sun JRE after 1.3. Actually, I recently saw that it still has an UTF string release bug in it, but apparently this doesn't cause any trouble (yet).
Sometimes the system architecture calls for layering multiple interfaces -- as in PL/SQL calling Java calling C++ -- and that can be tricky, because you have to respect all the different 'boundary conditions'. But on the whole JNI is much better than some other interfacing technologies I have seen; especially the ones designed for specific systems.
I have been using Java for a long time, for server software, server-side methods and client-side applications. In general, through not always, interacting with databases. I have also written C++ code, both for similar purposes and for hardware control.
My experience is that in a well-written Java application, the performance of the JVM is usually not the real cause of performance bottlenecks that can be felt by the user. Design errors can make Java code slow; it may be a relatively "easy" language but the programmer still has to understand very well what he or she is doing, and seemingly unimportant choices can have serious performance impact -- just as in C++.
Fortunately, understanding the system is much easier in Java than, in say, Visual C++ (to mention just one abomination from the deep.) I suspect that on average Java code contains fewer blunders with a serious performance impact than C++ code.
Certainly, for the really high-speed parts of the code and for specialized purposes I too would still recommend to use C++, but for 95% of all code there is no reason not to write it in Java. And it is fairly simple to integrate C++ code in Java.
I harbour a suspicion that programmers who insist on writing all code in C++ or even C because they think that it will be faster, are largely the same people who insist on writing labyrinthine, unstable and unmaintainable code because they think that is faster. As you may suspect, I don't have a high opinion of programmers in general: I think that in general, only a third of professional programmers can be called competent (enough) to safely handle tools such as C++. The rest should be kept in to a sandbox.
And besides, the majority of infuriatingly slow applications that I have seen were not written in Java: More typically these are the work of naive Visual C++ and Basic programmers, the kind of people who recalculate the layout of the entire screen when they need to change the display of a variable, or copy the content of an entire database to memory on start-up.
A caveat, however: Java performance can depend enormously on how your system is set up. For example, the way the on-access scan of McAfee antivirus handles the Java JRE and other libraries is a bloody disgrace and results in painfully and unacceptably long startup times. But that is hardly Sun's fault. (Note for the next job interview: Ask what virus scanner they use.)
I admit that relying on garbage collection can be unnerving for the C and C++ programmer. I think I was nervous about not explictly de-allocating memory for the first two years or so; then I got used to it. (And, despite finally acquiring Java habits, I do not forget to de-allocate in C++ code. If anything, I am more accurate in it than I used to be.)
Ironically -- and this should serve as another caveat -- the biggest memory leak I ever created was in Java, not in C++. What I had overlooked is that the GC will not get rid of memory if a reference to it has been passed to a dialog; and I had forgotten to dispose of the dialog, which (very indirectly) controlled the display of a large data set.
Your argument appears to be that software programmers should be allowed to indulge in practices known to be unsafe, only because they happen to work on the particular platform that they happen to be developing on.
Frankly, I don't even see why a software supplier should allow his developers to get away with that. Portability and maintainability are basic real-world criteria, not luxury features. They determine the value, not only of the application, but of the code and its potential use in future releases. Any supplier with business sense should ensure that the upgrades necessary to accomodate future software environments are (1) as small as possible and (2) well-documented and localised.
Actually, for once people should be allowed to blame Microsoft for their problems. Far too much modern software has badly documented OS depencies scattered all over it, instead of grouped in tool classes with clearly defined interfaces. I know at least one software team (and it was not even working for an IT company) that decided to write its own software library, re-implementing even the basics instead of relying on Microsoftisms, and found that this not only eliminated undesirable OS dependencies, but resulted in substantial gains in both performance and stability.
Progammers should be realistic about the environment in which their code has to live, and write their code defensively. I would call a null pointer read that does not cause problems with a given Kernel implementation, a bug. It is just fortunate that it has not been triggered yet, but it still is a bug.
It has to be admitted that the software environment in which an application has to run can be spectacularly bad, especially in large companies that are hostage to the tyranny of their IT departments. And of course, sometimes the environment does change in ways that would badly affect any code. But the excuse should not be invoked more often than is strictly necessary.
Actually, consumer software is not so bad, if you compare it to the software that is supplied with scientific instruments and research tools. This is a relatively small market, and its buyers have put up with software quality standards that are below par -- in part because so few of them are programmers themselves. Even at the high end of the market -- and that means upwards from 200,000 euros list price -- you will easily find instruments that fail because communication protocols have not been implemented properly, there are substantial memory or resource leaks, or methods have *never* been tested under remotely realistic conditions. It is fairly common to encounter software there that has incorrect storage of logs, writes data in absolutely impractical formats, or cannot re-export data (that it has internally!) if the first export attempt failed. If you study it more closely, you will find complicated DLLs or ActiveX interfaces, designed and used to control expensive instruments, that are undocumented or incorrectely documented. And as for the design of most user interfaces, it doesn't bear mentioning. And you would be mistaken to assume that the supplier of an instrument that is worth a house (or several houses) takes liability for bugs in its software. In fact, it is not impossible that they will actually charge the buyer for correcting their bugs. The good news: Most of these suppliers are glad to receive customer feedback...