The problem with flash content (for me at any rate) has been stability. On 64bit I've tried Adobe's preliminary native 64bit player, and it didn't work. So I'm back to using the nspluginwrapper to run the 32bit within my 64bit OS. After some period of time, the sound will go bad. Various other observations coming out of troubleshooting the sound layer led me to conclude that it is indeed the flash plugin that's wonky.
Checks and balances are a key design element of the constitution. The armed populace is a check for government officials. Perhaps not the best, but what's a good alternative? Another federal agency to act as a check against government corruption is probably what most of today's politicians would implement, but that doesn't seem to be a good choice.
Yeah, and it'll stay that way until someone figures out how to fix the lobbying problem. As long as the corporations decide who gets the bribage, they'll pick the people who can make them the most money and avoid the people who have a spine.
The advantage radio in the car still has over podcasting is news. Weather, traffic, etc can all change fast. Until there's enough of an informational network available with the reliability that the existing "radionet" has, radio will be more useful for such things.
What is the scope of the current licensing, as in which books are covered by the current agreement?
Do you envision being able to add future expansions/sequels/engine-using-content-environmen ts that allow for first age content, perhaps co-terminus with the Children of Hurin book just out? Or any other era? The flight of the Noldor from the west would also make a good high-power story arc.
Most games have an escalation of power as they get older, but with the LOTR mythos, the power diminishes over time. However, adding elements as alluded to above would fit the increased power design pattern, plus fit into the overall mythos with more elegance.
The real, core, problem behind bad software is a requirements issue.
There are several things that come to play here:
- People don't know what they want until they have it.
- Mass market products (office, browsers) use an averaging effect of either focus groups or "representative guessing" to determine requirements for people that won't know what they want til they have it.
- Users and developers don't want to talk to each other.
- If someone makes them get in a room, users and developers tend to talk in different directions, having different mental models of the domain space.
I'm sure there are more. That's the top few without writing a book.
There are a few elements in his answers that have some truth about them -- the constant panic and rush causing lower quality -- but they all tie back to these. The panic and rush are there because everyone is trying to patch over the problems and miscommunications several steps too late.
Additionally, the sorts of things that wouldn't make an academic or intellectual cry when reading code are artistic fluffery. Brilliantly clever "pretty" algorithms end up being unreadable and incomprehensible either at 3 in the morning or by the guy that's really just a coach at heart and is in your code. ("I'm in ur code, coaching ur variables")
The educational system in the US is designed to feed the corporate system in the US. dry, unchallenging, unmotivating.
There are some like Jack Welch in charge of companies, but not many. Not many at all. Most have somehow convinced themselves that the way to be competetive is to be more like other companies. The way to innovate is to implement the ideas that other people are implementing. I have seen it, and though I do not understand it, I see the connection here between the corporations and the educational system.
"We changed our pricing to be more in line with the other companies to be more competetive." Wrap your heads around that one.
The big hurdle in making software that does what a business needs is in finding out what the business needs its software to do. Trying to get requirements and user commitment from the business as an IT person is the big obstacle, and has been the failing point on the majority of projects I have seen.
Hiring people from another country is certainly not going to help that.
Pulling in consultants from our own country, speaking our own language, often causes enough of a communication and process familiarity gap to magnify the problem.
So the thought of trying to salve over this issue with this insane solution indicates to me that this guy is trying to do something entirely different.
Of course, the fact that he's a politician also tells me that what he's fundamentally trying to do is fill his pockets, or fill an intern. Or perhaps both.
"So basically, you don't know what you want, probably don't know why you want it, what it has to do, or what you're willing to spend on it, but you want the answer?"
If this surprises you, then you've never actually dealt directly with software end-users who were supposed to specify requirements. Perhaps you develop a shrink-wrap package? Or is it open source?
People don't know what they want until they have it. Then they can tell you "yes" or "no". Sometimes. If you're lucky.
It does with a large number of people. Humility is an amazing tool. Defuses a lot of the testosteronal willy-waving.
Though it's really all in the way it's done. People that refuse to acknowledge the reality of their dysfunctionally incorrect ideas don't get much respect. Neither to people that drop ideas at the drop of a hat.
The middle way is best here: gather evidence and go where it leads you. Let the evidence support your ideas, and you will be able to more compellingly get your ideas across to people, and get their respect, even when your ideas need to change in response to changing evidence.
The biggest problem today in business with respect to software is that people in business don't understand that the reason you have software in a business at all is to make the processes of that business more effective.
Instead, there is a notion that "well, our competitors have it", or "we have to have it or we'll go out of business".
If you're just playing catch-up with your competitors, you aren't. There's certainly no innovation going on in your company, and beyond that you have no competetive advantage. That would be "stuff that makes you DIFFERENT".
So -- there's a fundamental perception problem. Since transitioning from a relatively advanced-thinking commercial development shop to an insurance company almost 10 years ago, I've been seeing this problem.
Given all of this context, the quote toward the beginning of the article by the Stanford CIO shows that Stanford also doesn't get it:
"Just buying the software does not solve the problem. You have to change the institution, and that's something Stanford struggled with."
No. You write (or buy/obtain if it's commodotizeable, like word processing or web servers) software that works to make the processes that you have more effective. Sometimes you need to make adjustments to have them work together. One case where you'd need to change is if you had a team of 50 people that did nothing all day long but go and pull index cards out of the card catalog in response to user requests -- putting in a database would require them to change this task. But overall, the process would be much more effective. Looking for a book (in this case) would remain functionally the same sort of thing.
The problem with software of this nature, or any "black-box-off-the-shelf" core business software is that it always comes with its own agenda regarding what the core processes of the business should be. To implement, the business has to change the way it does business in order to map into this new set of processes. AND often pay millions of dollars for the privilege. So, the business has just lost some of its competetive advantage (distinctiveness), AND has to pay a BUNCH per month. Plus they all come with maintenance fees now. On top of the original ridiculous price tag.
Why don't these businesses just write their own, you may be asking? Sadly, the answer is rather simple. In order to find out what you need the software to do, you need to get the users together and find out from them what they do.
First, this will take time. Generally, in a business, if you stand up and say "I have time to be able to do this extra thing" it translates as "because I don't do anything anyway", which is managerial for "I am an expense that produces nothing, fire me". So people don't like being put in that position. Second, it's human nature to not have a good idea what it is that you are doing. Go read about contextual design for discussion on this subject, and ideas on a method of getting around it. Suffice to say, people don't give good information when just asked -- they need to be watched. Which is time intensive (see 1 above). So, even if you get volunteers, unless you use the special tricks, you get bad information. Which leads to an incorrect product. See the last 20-30 years of "the software problem" for references here.
Sounds like a bottomless pit. The way out seems to me to be to get the users educated as to why the software need exists in the first place, then once they're educated, get them motivated to work together to discover what the software needs to do.
Easier said than done. Here're your shovels, get digging!
I have had a hybrid (Honda Civic) for a little over a year. It's been reliable, and I've gotten good mileage out of it. Never the 48 MPG claimed, but I never give those marketing numbers much credit anyway. All in all, I am happy with the performance of the car as a hybrid, and would get another hybrid over another conventional civic in the future.
However, I think that there is a better option out there, that I would prefer to see come to fruition in the consumer market.
Biodiesel.
1) The mileage of the hybrid fluctuates as the weather fluctuates. Cold dramatically drops the performance. I get around 42mpg in spring and fall, I drop to 38-40 in high summer (the AC, I'm thinking), and drop to around 32-34 in winter. This is in a "standard" temperate area, no big extremes in either direction. Diesel has historically been more difficult to start in colder weather, but I've read that this has been changing. The mileage would still be high year-round with diesel. 2) In addition to weather, the particular nature of the trip affects the mileage and the charge remaining in the battery. At times this is a nuisance -- a quick jog to the store down the block can suck down half the battery. 3) Biodiesel can be produced from inter-regional plant product. No need to schlep un-replaceable crud from the other side of the planet. No need to ship local money to the other side of the planet. To be used to fund people that don't like us, and yet don't even know us. Much better to fund the people down the road that know us, but don't like us anyway.
The main thing keeping diesel cars from becoming commercial in the US is emmission standards. An article I read cited someone from Toyota saying that they anticipated being able to overcome these issues within 5 years.
If these things happen in this sort of timeframe, then I am one hybrid owner that will move over to a diesel car.
I have been tired of this "everything invent in Egypt" belief for years now.
- I have seen discussion of archeological evidence that not only was farming first performed in other areas (mesopotamia) first, but it was imported INTO Egypt. Further, other major regions in the world independently learned to farm their own different crops. Egypt did not teach the world how to farm. See "Guns, Germs and Steel" for supporting evidence here.
- I have seen no empirical evidence whatsoever presented to me in any way that there was ever any Egyptian control of gravity.
- You built the pyramids. An admitted accomplishment, but what do they do? They can be seen from space. So can the great wall of China. It kept out barbarians. The pyramids....well, you can see them from space.
It all reminds me of the father from "Big Fat Greek Wedding" claiming that every word comes from Greek.
Note particularly:
1980: Bell Labs finally shows interest in BSD Unix
-and-
1991: 05Oct: linux 0.02, first mention of directory-name 'linux' on netnews
Because once you air this sort of thing, it sort of kills your career.
It's often better to voice your concerns internally, and work to improve the system from within.
. ..
Jesus of Nazareth did not die so we could enjoy eggs and chocolate bunnies!
Jesus of Nazareth did not voice his concerns internally and work to improve the system from within. True change requires true sacrifice, which few are willing to make.
Off-the-shelf games have a terribly short life span. Other software does as well, but I reached this line of thought through the avenue of games. The general industry now uses a model of approximately "realease slightly premature, patch twice, move on to another product".
As such, if there's a particular type of game that you like to play a lot, over a period of many years, you have what I see are two choices: play a series of disconnected commercial games that come somewhat close to giving you the feeling of having played that sort of game for a while, or play an open source game of your chosen genre.
That's the reason to play. The reason to code is to put back into the community -- either you want to see a change to match your style, or you just want to do something to make sure that this product is still around for you in a few years.
The rules aren't the core issue. Other games have released the rules for free - VOID is a big example (very popular at our local store in the midwest US). The problem is in the miniatures themselves. Information may want to be free, but how do you "free" sculpts, casting, molds, molten metal, etc.? You could go the route that Reaper has done with CAV and make a mold from a CAD file, but that's an expensive route. Even if you freely share your designs, how would you "print" them out into white metal or even resin?
The admin tools for postgresql are there on win32 -- at least the pgadmin 2 tool that I use has been very easy. Better in a few ways than oracle's tools, and no worse in any. I like the fact that it's one tool (including the SQL exec tool), not 3 or 4.
I will give you the point that it was not nearly as easy to set up as it should have been. It requires cygwin, which will be off-putting to people that don't already have it, and I actually had to TYPE things in FILES. Which will freak people out. Also, it requires some cleanup when the system crashes, which involves deleting a lock file. This is one of those things that will cause people to think that it sucks, even though it's a trivial thing.
If they can get postgresql to install as smoothly as personal oracle did when last I had it on my system (4 years or so ago), they'll take care of this whole issue. I know that they're working on getting rid of the cygwin requirement, but I'm not sure where they are on the installation smoothing.
The problem that I have had with labelling software development as an engineering discipline is that in any engineering project, the requirements of that project are well and rigidly defined. As things change, they tend to change in some quantifiable way.
In my decade of working in the software development field, I have not once seen a development project where the users of the software accurately, completely and rigidly defined the requirements of their system, or had changes to the initial requirements specified in a quantifiable way.
User needs are vague and fuzzy, and change in response to urges like "That's not exactly what I had in mind." Though they can't elucidate WHAT they had in mind. This is typical, common, and the way that people work with respect to software.
As a result, what we do is more like a quasi-artistic design. The needs of an engineer to understand the physics behind structural stresses in a building is simply not something that exists in any analagous capacity for software developers. A small percentage do "hard" programming like device drivers, but that insulates the remaining programmers from having to deal with this level of difficulty. And unless the users of a system are dealing with physics and differential equations, the software won't either. It certainly won't with standard business software.
The difficult bits in developing software for people are in determining what they want the software to do. You have to get into their work-space and see how they want their world to work. Then you have to begin showing them prototypes, and iterate your way to the end result. As I describe it here, it sounds more like interior design than architecture. It certainly doesn't sound like how Engineering should be practiced.
Engineering doesn't work in an iterative fashion, and Software Development works best in an iterative fashion.
Since the difficult parts of software development, particularly for a business, involve communicating to users, there will be an implicit tarriff involved -- the price will go up in the long run because the software will not do the right thing, and will need to be recoded.
Unless you are closely tied to the user, and can observe their process and derive the needs for their software from that automation, you won't get the requirements right. The farther removed from this observational process, the more wrong the requirements are. The more the requirements are off, the more it will cost to fix the software. The software will suck.
Outsourcing at all is one degree of separation. Developers not at the place of business is a degree of separation. Developers that don't speak the same language as the users is at least one degree of separation. This list could easily be expanded, and is meant to give some simple examples, rather than be a comprehensive list.
My point is that the long-term cost of the software choice will increase. But, and here's the rub, in American business, nobody cares about the long term. The short-term quarterly lower initial price tag is what guides MBAs. So they buy the cheap stuff that will be more of a burden to the next vic in their seat. And their company will never realize that it is indeed paying a tarriff for having outsourced their software.
In college, in the 89-92 timeframe, I used macs for several things. Mathematica was a big draw, and graphical spreadsheets were nice as well. But for serious computation I gradually began to more use the PC's. Particularly once the 386 was released, the advantage was in the PC's court from my observations, particularly in the realm of task-switching.
I don't think that Mac caught up til OSX, and in that case I think they leapfrogged ahead. But the damage was done in the intervening decade.
Slashdot Mirror
The problem with flash content (for me at any rate) has been stability. On 64bit I've tried Adobe's preliminary native 64bit player, and it didn't work. So I'm back to using the nspluginwrapper to run the 32bit within my 64bit OS. After some period of time, the sound will go bad. Various other observations coming out of troubleshooting the sound layer led me to conclude that it is indeed the flash plugin that's wonky.
So, it's "there", but it's not stable yet.
etch-a-sketch!
Checks and balances are a key design element of the constitution. The armed populace is a check for government officials. Perhaps not the best, but what's a good alternative? Another federal agency to act as a check against government corruption is probably what most of today's politicians would implement, but that doesn't seem to be a good choice.
Yeah, and it'll stay that way until someone figures out how to fix the lobbying problem. As long as the corporations decide who gets the bribage, they'll pick the people who can make them the most money and avoid the people who have a spine.
Fixed that for you.
The advantage radio in the car still has over podcasting is news. Weather, traffic, etc can all change fast. Until there's enough of an informational network available with the reliability that the existing "radionet" has, radio will be more useful for such things.
This surprises you? Capitalism didn't *defeat* Communism, it *assimilated* it. And Fascism too.
What is the scope of the current licensing, as in which books are covered by the current agreement?
n ts that allow for first age content, perhaps co-terminus with the Children of Hurin book just out? Or any other era? The flight of the Noldor from the west would also make a good high-power story arc.
Do you envision being able to add future expansions/sequels/engine-using-content-environme
Most games have an escalation of power as they get older, but with the LOTR mythos, the power diminishes over time. However, adding elements as alluded to above would fit the increased power design pattern, plus fit into the overall mythos with more elegance.
The real, core, problem behind bad software is a requirements issue.
There are several things that come to play here:
- People don't know what they want until they have it.
- Mass market products (office, browsers) use an averaging effect of either focus groups or "representative guessing" to determine requirements for people that won't know what they want til they have it.
- Users and developers don't want to talk to each other.
- If someone makes them get in a room, users and developers tend to talk in different directions, having different mental models of the domain space.
I'm sure there are more. That's the top few without writing a book.
There are a few elements in his answers that have some truth about them -- the constant panic and rush causing lower quality -- but they all tie back to these. The panic and rush are there because everyone is trying to patch over the problems and miscommunications several steps too late.
Additionally, the sorts of things that wouldn't make an academic or intellectual cry when reading code are artistic fluffery. Brilliantly clever "pretty" algorithms end up being unreadable and incomprehensible either at 3 in the morning or by the guy that's really just a coach at heart and is in your code. ("I'm in ur code, coaching ur variables")
maintainability and readability ftw.
The educational system in the US is designed to feed the corporate system in the US. dry, unchallenging, unmotivating.
There are some like Jack Welch in charge of companies, but not many. Not many at all. Most have somehow convinced themselves that the way to be competetive is to be more like other companies. The way to innovate is to implement the ideas that other people are implementing. I have seen it, and though I do not understand it, I see the connection here between the corporations and the educational system.
"We changed our pricing to be more in line with the other companies to be more competetive." Wrap your heads around that one.
The big hurdle in making software that does what a business needs is in finding out what the business needs its software to do. Trying to get requirements and user commitment from the business as an IT person is the big obstacle, and has been the failing point on the majority of projects I have seen.
Hiring people from another country is certainly not going to help that.
Pulling in consultants from our own country, speaking our own language, often causes enough of a communication and process familiarity gap to magnify the problem.
So the thought of trying to salve over this issue with this insane solution indicates to me that this guy is trying to do something entirely different.
Of course, the fact that he's a politician also tells me that what he's fundamentally trying to do is fill his pockets, or fill an intern. Or perhaps both.
"So basically, you don't know what you want, probably don't know why you want it, what it has to do, or what you're willing to spend on it, but you want the answer?"
If this surprises you, then you've never actually dealt directly with software end-users who were supposed to specify requirements. Perhaps you develop a shrink-wrap package? Or is it open source?
People don't know what they want until they have it. Then they can tell you "yes" or "no". Sometimes. If you're lucky.
It does with a large number of people. Humility is an amazing tool. Defuses a lot of the testosteronal willy-waving.
Though it's really all in the way it's done. People that refuse to acknowledge the reality of their dysfunctionally incorrect ideas don't get much respect. Neither to people that drop ideas at the drop of a hat.
The middle way is best here: gather evidence and go where it leads you. Let the evidence support your ideas, and you will be able to more compellingly get your ideas across to people, and get their respect, even when your ideas need to change in response to changing evidence.
The biggest problem today in business with respect to software is that people in business don't understand that the reason you have software in a business at all is to make the processes of that business more effective.
Instead, there is a notion that "well, our competitors have it", or "we have to have it or we'll go out of business".
If you're just playing catch-up with your competitors, you aren't. There's certainly no innovation going on in your company, and beyond that you have no competetive advantage. That would be "stuff that makes you DIFFERENT".
So -- there's a fundamental perception problem. Since transitioning from a relatively advanced-thinking commercial development shop to an insurance company almost 10 years ago, I've been seeing this problem.
Given all of this context, the quote toward the beginning of the article by the Stanford CIO shows that Stanford also doesn't get it:
"Just buying the software does not solve the problem. You have to change the institution, and that's something Stanford struggled with."
No. You write (or buy/obtain if it's commodotizeable, like word processing or web servers) software that works to make the processes that you have more effective. Sometimes you need to make adjustments to have them work together. One case where you'd need to change is if you had a team of 50 people that did nothing all day long but go and pull index cards out of the card catalog in response to user requests -- putting in a database would require them to change this task. But overall, the process would be much more effective. Looking for a book (in this case) would remain functionally the same sort of thing.
The problem with software of this nature, or any "black-box-off-the-shelf" core business software is that it always comes with its own agenda regarding what the core processes of the business should be. To implement, the business has to change the way it does business in order to map into this new set of processes. AND often pay millions of dollars for the privilege. So, the business has just lost some of its competetive advantage (distinctiveness), AND has to pay a BUNCH per month. Plus they all come with maintenance fees now. On top of the original ridiculous price tag.
Why don't these businesses just write their own, you may be asking? Sadly, the answer is rather simple. In order to find out what you need the software to do, you need to get the users together and find out from them what they do.
First, this will take time. Generally, in a business, if you stand up and say "I have time to be able to do this extra thing" it translates as "because I don't do anything anyway", which is managerial for "I am an expense that produces nothing, fire me". So people don't like being put in that position. Second, it's human nature to not have a good idea what it is that you are doing. Go read about contextual design for discussion on this subject, and ideas on a method of getting around it. Suffice to say, people don't give good information when just asked -- they need to be watched. Which is time intensive (see 1 above). So, even if you get volunteers, unless you use the special tricks, you get bad information. Which leads to an incorrect product. See the last 20-30 years of "the software problem" for references here.
Sounds like a bottomless pit. The way out seems to me to be to get the users educated as to why the software need exists in the first place, then once they're educated, get them motivated to work together to discover what the software needs to do.
Easier said than done. Here're your shovels, get digging!
I have had a hybrid (Honda Civic) for a little over a year. It's been reliable, and I've gotten good mileage out of it. Never the 48 MPG claimed, but I never give those marketing numbers much credit anyway. All in all, I am happy with the performance of the car as a hybrid, and would get another hybrid over another conventional civic in the future.
However, I think that there is a better option out there, that I would prefer to see come to fruition in the consumer market.
Biodiesel.
1) The mileage of the hybrid fluctuates as the weather fluctuates. Cold dramatically drops the performance. I get around 42mpg in spring and fall, I drop to 38-40 in high summer (the AC, I'm thinking), and drop to around 32-34 in winter. This is in a "standard" temperate area, no big extremes in either direction. Diesel has historically been more difficult to start in colder weather, but I've read that this has been changing. The mileage would still be high year-round with diesel.
2) In addition to weather, the particular nature of the trip affects the mileage and the charge remaining in the battery. At times this is a nuisance -- a quick jog to the store down the block can suck down half the battery.
3) Biodiesel can be produced from inter-regional plant product. No need to schlep un-replaceable crud from the other side of the planet. No need to ship local money to the other side of the planet. To be used to fund people that don't like us, and yet don't even know us. Much better to fund the people down the road that know us, but don't like us anyway.
The main thing keeping diesel cars from becoming commercial in the US is emmission standards. An article I read cited someone from Toyota saying that they anticipated being able to overcome these issues within 5 years.
If these things happen in this sort of timeframe, then I am one hybrid owner that will move over to a diesel car.
I have been tired of this "everything invent in Egypt" belief for years now.
- I have seen discussion of archeological evidence that not only was farming first performed in other areas (mesopotamia) first, but it was imported INTO Egypt. Further, other major regions in the world independently learned to farm their own different crops. Egypt did not teach the world how to farm. See "Guns, Germs and Steel" for supporting evidence here.
- I have seen no empirical evidence whatsoever presented to me in any way that there was ever any Egyptian control of gravity.
- You built the pyramids. An admitted accomplishment, but what do they do? They can be seen from space. So can the great wall of China. It kept out barbarians. The pyramids....well, you can see them from space.
It all reminds me of the father from "Big Fat Greek Wedding" claiming that every word comes from Greek.
Note particularly:
1980: Bell Labs finally shows interest in BSD Unix
-and-
1991: 05Oct: linux 0.02, first mention of directory-name 'linux' on netnews
Jesus of Nazareth did not voice his concerns internally and work to improve the system from within. True change requires true sacrifice, which few are willing to make.
baby come, language go.
Someday, you know this.
(leaving words out also beats the alternative... "wipey pipey baby wabey" )
Off-the-shelf games have a terribly short life span. Other software does as well, but I reached this line of thought through the avenue of games. The general industry now uses a model of approximately "realease slightly premature, patch twice, move on to another product".
As such, if there's a particular type of game that you like to play a lot, over a period of many years, you have what I see are two choices: play a series of disconnected commercial games that come somewhat close to giving you the feeling of having played that sort of game for a while, or play an open source game of your chosen genre.
That's the reason to play. The reason to code is to put back into the community -- either you want to see a change to match your style, or you just want to do something to make sure that this product is still around for you in a few years.
This makes me proud to run BSD on my home server.
The rules aren't the core issue. Other games have released the rules for free - VOID is a big example (very popular at our local store in the midwest US). The problem is in the miniatures themselves. Information may want to be free, but how do you "free" sculpts, casting, molds, molten metal, etc.? You could go the route that Reaper has done with CAV and make a mold from a CAD file, but that's an expensive route. Even if you freely share your designs, how would you "print" them out into white metal or even resin?
The admin tools for postgresql are there on win32 -- at least the pgadmin 2 tool that I use has been very easy. Better in a few ways than oracle's tools, and no worse in any. I like the fact that it's one tool (including the SQL exec tool), not 3 or 4.
I will give you the point that it was not nearly as easy to set up as it should have been. It requires cygwin, which will be off-putting to people that don't already have it, and I actually had to TYPE things in FILES. Which will freak people out. Also, it requires some cleanup when the system crashes, which involves deleting a lock file. This is one of those things that will cause people to think that it sucks, even though it's a trivial thing.
If they can get postgresql to install as smoothly as personal oracle did when last I had it on my system (4 years or so ago), they'll take care of this whole issue. I know that they're working on getting rid of the cygwin requirement, but I'm not sure where they are on the installation smoothing.
The problem that I have had with labelling software development as an engineering discipline is that in any engineering project, the requirements of that project are well and rigidly defined. As things change, they tend to change in some quantifiable way.
In my decade of working in the software development field, I have not once seen a development project where the users of the software accurately, completely and rigidly defined the requirements of their system, or had changes to the initial requirements specified in a quantifiable way.
User needs are vague and fuzzy, and change in response to urges like "That's not exactly what I had in mind." Though they can't elucidate WHAT they had in mind. This is typical, common, and the way that people work with respect to software.
As a result, what we do is more like a quasi-artistic design. The needs of an engineer to understand the physics behind structural stresses in a building is simply not something that exists in any analagous capacity for software developers. A small percentage do "hard" programming like device drivers, but that insulates the remaining programmers from having to deal with this level of difficulty. And unless the users of a system are dealing with physics and differential equations, the software won't either. It certainly won't with standard business software.
The difficult bits in developing software for people are in determining what they want the software to do. You have to get into their work-space and see how they want their world to work. Then you have to begin showing them prototypes, and iterate your way to the end result. As I describe it here, it sounds more like interior design than architecture. It certainly doesn't sound like how Engineering should be practiced.
Engineering doesn't work in an iterative fashion, and Software Development works best in an iterative fashion.
Since the difficult parts of software development, particularly for a business, involve communicating to users, there will be an implicit tarriff involved -- the price will go up in the long run because the software will not do the right thing, and will need to be recoded.
Unless you are closely tied to the user, and can observe their process and derive the needs for their software from that automation, you won't get the requirements right. The farther removed from this observational process, the more wrong the requirements are. The more the requirements are off, the more it will cost to fix the software. The software will suck.
Outsourcing at all is one degree of separation. Developers not at the place of business is a degree of separation. Developers that don't speak the same language as the users is at least one degree of separation. This list could easily be expanded, and is meant to give some simple examples, rather than be a comprehensive list.
My point is that the long-term cost of the software choice will increase. But, and here's the rub, in American business, nobody cares about the long term. The short-term quarterly lower initial price tag is what guides MBAs. So they buy the cheap stuff that will be more of a burden to the next vic in their seat. And their company will never realize that it is indeed paying a tarriff for having outsourced their software.
In college, in the 89-92 timeframe, I used macs for several things. Mathematica was a big draw, and graphical spreadsheets were nice as well. But for serious computation I gradually began to more use the PC's. Particularly once the 386 was released, the advantage was in the PC's court from my observations, particularly in the realm of task-switching.
I don't think that Mac caught up til OSX, and in that case I think they leapfrogged ahead. But the damage was done in the intervening decade.