"I predict that many Republicans will oppose this bill,... but, becuase the industry that they would be tasked to protect is one that generally opposses them."
You forget the one thing that all politicians value most: The almighty dollar. Once the lobbyists start handing out "campaign donations" you will see every idiot believing in the wisdom of the RIAA/MPAA.
Of course my right to backup copies will be ignored because I do not even have the money to get my representative to blink. I only get lip service from him every two years near election time.
...how many websites there relied on active x code that was incompatible with Vista,
Actually, the problem was not in vista, but with the "enhanced" security of IE 7. It was pretty bad, a lot of banking and financial sites were broken in IE 7. At the time, Microsoft was contemplating making it a required update for automatic updates.
However, Monopolies are bad. This is a clear case of a monopoly using its power to stifle long term competition at a short term profit loss.
Do you honestly think Microsoft would offer both an OS and Office for $3 if it wasn't trying to stifle competition? As soon as the OLPC project is broke and a memory, expect the price of Microsoft's software to increase exponentially.
If you read the article (actually look at the pretty chart) Diabetes and some cancer are still higher risks for moderately overweight people. It is just that there are far fewer deaths added from these causes than the number of deaths removed from other causes.
Also, the article summary is misleading because it fails to mention that obesity is still a huge health risk in most cases.
He is busy. I saw him do some his best work ever. It was a recent project produced and directed by his daughter. He was *playing* the role of a drunk...
The article is pathetic. The author makes a haphazard attempt to explain the current situation then draws his conclusion. He does not explain how he arrived at that conclusion or give any evidence.
The Psychic Friends network gives better supporting evidence.
Its a sugar to Hydrogen technology.
Every grocery store already sells tons of sugar and in a liquid form regularly. It is called soda. It is proof that distribution system is already in place and cheap to boot. It comes in convenient 2 liter bottles selling 50 cents(no-name brand) which comes to less then 1/3 the current price of gasoline.
As far as I am concerned Stargate SG1 "jumped the shark" when Annubis was killed. Since then the show has been in decline. When Vala joined the cast, she was so annoying that I knew that the end was near. With the last two seasons and the major cast changes(and lackluster interest in Atlantis), I completely stopped watching all Stargate. I have no interest in the future movies because I never liked the shows since the Ori came to be.
I don't work on these large-scale projects, but most business programming I've seen falls into the "can hack together in Perl in a few weeks" category. Pretty much any web application short of Google falls into that category as well. That should be plenty to keep me busy.
mandelbr0t
If all your experience comes down to this and you never worked on an enterprise sized project than you have lost all credibility to create your parent post.
Most programs I have seen and written in COBOL can not be turned into a perl hack in a few weeks. (I am not knock perl, just mandelbr0t's logical ability.) Many systems have complex business rules and can take months if not a few years to fully implement. To believe that you can take these programs and hack a program out of it in a few weeks show you do not understand them at all.
The point is why rewrite something that works fine already. These COBOL applications work well now, some do have significant documentation, and believe it or not some (not many) have been rewritten (or just developed) recently.
Before you think I am clueless ponder this. COBOL has a proven track record of over 40 years. Over that time is has matured and became very stable. It is reliable and quick.
Some COBOL Applications handle massive amounts of data that many servers would choke on. (Admittedly this is mostly due to the hardware architecture.) I personally wrote a program that would process over 35GB daily in about 10minutes. How many servers can process that amount of information? How many languages would you trust to deal with that quantity of information? Think of how much even the smallest memory leak in a language would be compounded with the sheer volume of data that we are talking about.
The Y2K crisis happened because programmers wrote programs that far exceeded the length of time they were initially expected to be used. 20 years ago, programmers used only 2 bytes for the year because they a) did not expect the program to be around in 2000, and b) memory and storage space required a premium price. For the most part it wasn't because they were bad programmer, they tried to be efficient programmers and the program lasted far better than they ever thought it would. Now a neophyte thinks it is a requirement to rewrite any program just because it is old(over 3 years). If you code haphazardly and do not think about future maintenance you may be forced to rewrite old code, but if you code with foresight you make the underly structure easy to maintain and upgrade.
The Y2K crisis also did one other thing. It made people re-evaluate their current needs and see if they were being met. The people who stayed with COBOL did so consciously. They made the decison that COBOL was fulfilling their needs or the programs would have been ported then (time permitting of course)
And yes, there is even new development with COBOL. The program I mentioned above with the 35GB of data was brand new and written in 2002. It processes returned billing information to AT&T from the LECs (Local Exchange Carriers) daily.
Now, I know someone is going to say that I am a biased old fart, but I am in my 30's, and the specific program I mentioned was my last COBOL program I wrote before becoming a Web Developer. The group I was with is still working with COBOL, but I moved on because even though it works well, I find writing COBOL too easy and monotonous. But the reliability, stability, and 40+ years of applications developed for it are why COBOL is still around and why it will still be around for a long time to come.
Actually, They already F**KED with the Gorn. The did it in the last season of Enterprise when they captured the Defiant in the alternate time line. The Gorn looked really cool.
Can intel be that smart promoting VIIV's DRM capabilities at a time when they are losing market share to AMD?
On Wall Street, AMD is currently gaining market share from Intel. (slowly, but surely)
As a consumer, I see AMD with a better price-to-performance ratio then Intel. Also AMD's chips require less electricity for that performance.
Now throw DRM into the mix and what am I going to buy? A DRM enabled chip that costs more, or a chip that is DRM-Free, costs less, and performs better?
It sounds like Intel is shooting themselves in the foot...
The infuriating thing about "economic" is that it periodically annoints technologies which all Right Thinking Persons know are blasphemous, such as: Windows (compared to Mac OS or Gnu/Linux), or VHS (vs Betamax), or Infix Notation (vs Postfix), or MKS (vs CGS), or Vi (vs. Emacs), or Visual Basic (vs. Lisp), or the Dallas Cowboys (vs. the Green Bay Packers), or GSM (vs. CDMA), or Complex Numbers (vs. Quaternions), or the Hummer (vs. the Prius), or the body image of Kate Moss (vs. that of Scarlett Johansen), or that of Brad Pitt (vs. that of Jack Black), or ABBA (vs. Silkworm), or Old Coke (vs. New Coke); or George Bush (vs. George McGovern).
With the current story you forgot the one relevant comparison: ASP (vs. Cold Fusion)
Also, kudos... It is always good to see a positive reference to Apocalyptica tossed into a tech discussion.
The devil has said that they are anxiously awaiting hell's first snowfall. The temperature is going to drop to well below freezing and Route 666 will freeze over.
Absolutely, but to generalize their contribution to modern computing as nothing more than theft and good marketing is pure garbage.
Ok, that's your opinion. I however beleive that they have only copied and stolen products without any real innovation.
Microsoft started by selling BASIC intepreters for the old Altair computers. However, their compilers were mainly based on public domain alternatives at the time. (Copy and/or stolen, not innovation)
As we progress to the era of DOS, When M$ was approach by IBM, they said they had a CP/M clone (but didn't) and bought the rights to QDOS which they resold as their own. (Clone of CP/M which they bought)
Further history of Microsoft reveals much more of the same.
Windows - Copy of the Mac's Gui which was stolen from Xerox PARC
Word - There were some many prior entrants I do not remember which was the first, but it wasn't M$. (unless maybe it was EDLIN which was horrendous to work with)
Excel - Clone of Lotus 1-2-3 which was a clone of Visicalc
Access - one of the first PC database I remember was dbase - but there was probably something earlier.
Money - This was only developed because a judge refuse to let M$ buy Quicken
Drivespace (Disk Compression) - wasn't around until after Stacker. (there was a big lawsuit on this one too! (Microsoft Lost)
Visio - This was written by a seperate company until M$ bought them in 2000.
Tablet PCs - Another lawsuit on this one a few years back because it is based on prior "Pen Computing"
Even M$ Bob, the OS flop which came back to haunt us as the stupid paperclip in M$ Office was a copy. I think it came from the avatar from the now defunct Sierra Network.
Internet Explorer, Recycle Bin/Undelete, Disk Defragmenter... - All are more examples of other people's ideas that Microsoft incorporated into the OS as their own.
Microsoft is a monopoly and does not innovate. I have shown multiple examples of this. Microsoft will buy or copy things that are truly innovative and then try to rewrite history as if they were their own all of history.
You have not given even one example of Microsoft innovation. When you do I may consider your post valid.
Quality code CAN happen... but first things must change...
Right now the environment in the business world today prevents truly bug-free programming. A lot needs to change:
1 - Fire all the programmers and developers that can't program. We all know which ones in the group fit into this category. Unfortunately our bosses don't know. They're the ones that cause the majority of the bugs. They came into the industry just for money (pre-2000 bust) and they have no real feel for programming yet they know how to email the boss. Keep the ones that are naturals. The real code warriors. The good ones know when to code new source, when to copy old source, and how to clean up old source when they copy it into their new modules.
2 - Get rid of the bosses that don't know tech people. (i.e. the ones that don't know the difference from #1 above) The boss doesn't need to know tech (it does help) but they do need to know their people. They also need to know how to keep office politics and beauracracy away from their people.
3 - Get rid of separate New Development and Maintenance groups. People will code better when they know they will have to fix their own code when it goes into production. They will care more about stability instead of features. Also, a programmer learns the difference between good and bad coding techniques when they are forced to maintain both. When you are maintaining programs you learn how to right code that is easier to fix or modify later; if all you do is new development you will never learn this key concept.
4 - After the requirements are requested and the specs/design is created don't let users change them. I can't change everything just because a user changes their mind. If I have to change, the release date is pushed back as if I just started the design today. I can't complete a program until you are done knowing what you want it to do.
5 - Procedural vs. Object Orientated programming. The huge developement debate. I admit I am biased toward Procedural programming. However, you should use whatever works better for your project. A GUI works better when you design using OOP, but when you need to crunch numbers on 10 million records procedural will work a lot better. I know a lot has been said about the poor code quality of OOP in particular, but if you get rid of the idiots in #1, the logic should be easy to follow.
6 - KISS - Keep It Simple Stupid - I used to work with someone very intelligent, but his code was terrible. He would program elaborate functions just to add two numbers together. My honest belief is that he tried to impress us with his "coding ability." If someone needs a simple program give them a simple program, don't redesign the wheel.
7 - Shoot and KILL everyone that sponsors or participates in a unreadable source code competition. (sorry personal peeve) We need to promote legible code with indenting and good, clear, and relevant variable naming.
8 - Quality. CMM, ISO, TQI. These are nothing more than BULLSH!T. While there some occasional insights coming from these "Quality" initiatives I disagree with most of the methods. Unfortunately, most of this initiatives are nothing more than feelgood bs for clueless management. Commenting and documenting your code is a good thing. However, these "quality" processes can also cause over-documentation. If you spend more time documenting your code than it will take to rewrite your system, you have documented too much. No one will sit through reading 50 hours of documentation to fix a small bug. When your documentaion helps explains why your code is doing obscure things to save the time of the person after you (or even remind yourself months later) you have the proper level of documentation/comments. I honestly believe that some of these initiatives create tons of documents so consulting/contracting companies can increase billable hours.
9 - Admins and Tech Writers. Hire all the good ones back. The improve our ability to code by letting us
4 - After the requirements are requested and the specs/design is created don't let users change them.
I'd say as an absolute, this is a sure way to get out of business.
I admit that his can be a little extreme; but if we are looking to keep bugs out of code it can be a necessity.
In your example, you talk about building a house. While adding an outlet is generally a simple thing and it may be easy to modify the floorplan for this; The builders will still need to make sure that the electrical system they planned for the house can handle the extra output (possibly having to replace it if not), they will need to check that the new plans are still up to code for the local housing regulations, and they will still need to run new wire to the outlet. Running the new wire is A LOT EASIER if the interior wall are not already in place, and if the house is half built, some walls may alreay be in place. This is need for adding a few simple outlets; think of how this is multiplied
Excellent, I agree with you. I also consider myself an oldbie. (20 years of programming, 12 years being paid for it) Fortunately in the early years I had a teacher that actually emphasize design and comments.
Unfortunately the environment in the business world today prevents truly bug-free programming. A lot needs to change:
1 - Fire all the programmers and developers that can't program. We all know which ones in the group fit into this category. Unfortunately our bosses don't know. They're the ones that cause the majority of the bugs. They came into the industry just for money (pre-2000 bust) and they have no real feel for programming yet they know how to email the boss. Keep the ones that are naturals. The real code warriors. The good ones know when to code new source, when to copy old source, and how to clean up old source when they copy it into their new modules.
2 - Get rid of the bosses that don't know tech people. (i.e. the ones that don't know the difference from #1 above) The boss doesn't need to know tech (it does help) but they do need to know their people. They also need to know how to keep office politics and beauracracy away from their people.
3 - Get rid of separate New Development and Maintenance groups. People will code better when they know they will have to fix their own code when it goes into production. They will care more about stability instead of features. Also, a programmer learns the difference between good and bad coding techniques when they are forced to maintain both.
4 - After the requirements are requested and the specs/design is created don't let users change them. I can't change everything just because a user changes their mind. If I have to change, the release date is pushed back as if I just started the design today. I can't complete a program until you are done knowing what you want it to do.
5 - Procedural vs. Object Orientated programming. The huge developement debate. I admit I am biased toward Procedural programming. However, you should use whatever works better for your project. A GUI works better when you design using OOP, but when you need to crunch numbers on 10 million records procedural will work a lot better. I know a lot has been said about the poor code quality of OOP in particular, but if you get rid of the idiots in #1, the logic should be easy to follow.
6 - KISS - Keep It Simple Stupid - I used to work with someone very intelligent, but his code was terrible. He would program elaborate functions just to add two numbers together. My honest belief is that he tried to impress us with his "coding ability." If someone needs a simple program give them a simple program, don't redesign the wheel.
7 - Shoot and KILL everyone that sponsors or participates in a unreadable source code competition. (sorry personal peeve) We need to promote legible code with indenting and good, clear, and relevant variable naming.
8 - Quality. CMM, ISO, TQI. These are nothing more than BULLSH!T. While there some occasional insights coming from these "Quality" initiatives I disagree with most of the methods. Commenting and documenting your code is a good thing. Unfortunately, most of this initiatives are nothing more than feelgood bs for clueless management.
9 - Admins and Tech Writers. Hire all the good ones back. The improve our ability to code by letting us use admins to do the less technical aspects of our jobs. Their hourly cost is less than ours and by offloading some of our work to them we have more time to develop the system that managent wants done yesterday. This creates more cost effective development even though it raises headcount.
10 - Pay. Simple answer. You get what you pay for. If you offer good pay for good programmers you will get good code in return provided your managers need know their programmers (see #2 above)
11 - Overtime. Don't do it. An overworked, stressed developer is a poor quality developer. A little OT before a release isn't terrible, but 50+ hour weeks for months on end will cause poor code. Also, if a little OT before a release happens, compensate the developer with pay or comp time to make them happy.
12 - TEST TEST TEST TEST TEST TEST. Then test some more. Make sure your users test also. This is the most important step.
Re:Do you think 3D graphics will enhance gameplay?
on
Ask The Civ IV Dev Team
·
· Score: 2, Interesting
I Agree. I am an oldtime gamer now. I want to know what game play enhancements you are creating. I am not interested in how the new version is pretty and uses 3d graphics. What are you doing to the underlying game to get me addicted to it?
Doesn't example.com also work for situations like this?
Personally, when I use a fake email address, I use something like bill.gates@microsoft.com. That way I get what I want and Microsoft gets spammed. A win-win situation in my mind.:)
attn: Humorless Moderators: You can mod me as a troll, but I bet most people giggled or plan on trying this the next time they are asked for their email address.
...doesn't utilizing 100% of a CPU result in a significant increase in power consumption...
Yes, but that is not all...
Your CPU is cooled by pulling in cool air(relatively speaking) from outside your case and pushing the hotter air out the back. Then the A/C in your house needs to cool the hot air produced by the computer. So you will have to pay more money to run your home's A/C.
Slashdot Mirror
"I predict that many Republicans will oppose this bill, ... but, becuase the industry that they would be tasked to protect is one that generally opposses them."
You forget the one thing that all politicians value most: The almighty dollar. Once the lobbyists start handing out "campaign donations" you will see every idiot believing in the wisdom of the RIAA/MPAA.
Of course my right to backup copies will be ignored because I do not even have the money to get my representative to blink. I only get lip service from him every two years near election time.
Actually, the problem was not in vista, but with the "enhanced" security of IE 7. It was pretty bad, a lot of banking and financial sites were broken in IE 7. At the time, Microsoft was contemplating making it a required update for automatic updates.
Competition is good...
However, Monopolies are bad. This is a clear case of a monopoly using its power to stifle long term competition at a short term profit loss.
Do you honestly think Microsoft would offer both an OS and Office for $3 if it wasn't trying to stifle competition? As soon as the OLPC project is broke and a memory, expect the price of Microsoft's software to increase exponentially.
If you read the article (actually look at the pretty chart) Diabetes and some cancer are still higher risks for moderately overweight people. It is just that there are far fewer deaths added from these causes than the number of deaths removed from other causes.
Also, the article summary is misleading because it fails to mention that obesity is still a huge health risk in most cases.
Actually, Thanks to skynet he be be sent back to yesterday. The exact number of years depending on the specific movie.
He is busy. I saw him do some his best work ever. It was a recent project produced and directed by his daughter. He was *playing* the role of a drunk...
The article is pathetic. The author makes a haphazard attempt to explain the current situation then draws his conclusion. He does not explain how he arrived at that conclusion or give any evidence. The Psychic Friends network gives better supporting evidence.
Its a sugar to Hydrogen technology. Every grocery store already sells tons of sugar and in a liquid form regularly. It is called soda. It is proof that distribution system is already in place and cheap to boot. It comes in convenient 2 liter bottles selling 50 cents(no-name brand) which comes to less then 1/3 the current price of gasoline.
As far as I am concerned Stargate SG1 "jumped the shark" when Annubis was killed. Since then the show has been in decline. When Vala joined the cast, she was so annoying that I knew that the end was near. With the last two seasons and the major cast changes(and lackluster interest in Atlantis), I completely stopped watching all Stargate. I have no interest in the future movies because I never liked the shows since the Ori came to be.
mandelbr0t,
The point is why rewrite something that works fine already. These COBOL applications work well now, some do have significant documentation, and believe it or not some (not many) have been rewritten (or just developed) recently.
Before you think I am clueless ponder this.
COBOL has a proven track record of over 40 years. Over that time is has matured and became very stable. It is reliable and quick.
Some COBOL Applications handle massive amounts of data that many servers would choke on. (Admittedly this is mostly due to the hardware architecture.) I personally wrote a program that would process over 35GB daily in about 10minutes. How many servers can process that amount of information? How many languages would you trust to deal with that quantity of information? Think of how much even the smallest memory leak in a language would be compounded with the sheer volume of data that we are talking about.
The Y2K crisis happened because programmers wrote programs that far exceeded the length of time they were initially expected to be used. 20 years ago, programmers used only 2 bytes for the year because they a) did not expect the program to be around in 2000, and b) memory and storage space required a premium price. For the most part it wasn't because they were bad programmer, they tried to be efficient programmers and the program lasted far better than they ever thought it would. Now a neophyte thinks it is a requirement to rewrite any program just because it is old(over 3 years). If you code haphazardly and do not think about future maintenance you may be forced to rewrite old code, but if you code with foresight you make the underly structure easy to maintain and upgrade.
The Y2K crisis also did one other thing. It made people re-evaluate their current needs and see if they were being met. The people who stayed with COBOL did so consciously. They made the decison that COBOL was fulfilling their needs or the programs would have been ported then (time permitting of course)
And yes, there is even new development with COBOL. The program I mentioned above with the 35GB of data was brand new and written in 2002. It processes returned billing information to AT&T from the LECs (Local Exchange Carriers) daily.
Now, I know someone is going to say that I am a biased old fart, but I am in my 30's, and the specific program I mentioned was my last COBOL program I wrote before becoming a Web Developer. The group I was with is still working with COBOL, but I moved on because even though it works well, I find writing COBOL too easy and monotonous. But the reliability, stability, and 40+ years of applications developed for it are why COBOL is still around and why it will still be around for a long time to come.
Actually, They already F**KED with the Gorn. The did it in the last season of Enterprise when they captured the Defiant in the alternate time line. The Gorn looked really cool.
Can intel be that smart promoting VIIV's DRM capabilities at a time when they are losing market share to AMD?
On Wall Street, AMD is currently gaining market share from Intel. (slowly, but surely)
As a consumer, I see AMD with a better price-to-performance ratio then Intel. Also AMD's chips require less electricity for that performance.
Now throw DRM into the mix and what am I going to buy? A DRM enabled chip that costs more, or a chip that is DRM-Free, costs less, and performs better?
It sounds like Intel is shooting themselves in the foot...
With the current story you forgot the one relevant comparison: ASP (vs. Cold Fusion)
Also, kudos... It is always good to see a positive reference to Apocalyptica tossed into a tech discussion.
I liked this story better...
...when it was new 4 days ago.
Actually I thought the story was just as boring and non-newsworthy then.
The devil has said that they are anxiously awaiting hell's first snowfall. The temperature is going to drop to well below freezing and Route 666 will freeze over.
Absolutely, but to generalize their contribution to modern computing as nothing more than theft and good marketing is pure garbage.
Ok, that's your opinion. I however beleive that they have only copied and stolen products without any real innovation.
Microsoft started by selling BASIC intepreters for the old Altair computers. However, their compilers were mainly based on public domain alternatives at the time. (Copy and/or stolen, not innovation)
As we progress to the era of DOS, When M$ was approach by IBM, they said they had a CP/M clone (but didn't) and bought the rights to QDOS which they resold as their own. (Clone of CP/M which they bought)
Further history of Microsoft reveals much more of the same.
Microsoft is a monopoly and does not innovate. I have shown multiple examples of this. Microsoft will buy or copy things that are truly innovative and then try to rewrite history as if they were their own all of history.
You have not given even one example of Microsoft innovation. When you do I may consider your post valid.
Quality code CAN happen... but first things must change...
Right now the environment in the business world today prevents truly bug-free programming. A lot needs to change:
1 - Fire all the programmers and developers that can't program. We all know which ones in the group fit into this category. Unfortunately our bosses don't know. They're the ones that cause the majority of the bugs. They came into the industry just for money (pre-2000 bust) and they have no real feel for programming yet they know how to email the boss. Keep the ones that are naturals. The real code warriors. The good ones know when to code new source, when to copy old source, and how to clean up old source when they copy it into their new modules.
2 - Get rid of the bosses that don't know tech people. (i.e. the ones that don't know the difference from #1 above) The boss doesn't need to know tech (it does help) but they do need to know their people. They also need to know how to keep office politics and beauracracy away from their people.
3 - Get rid of separate New Development and Maintenance groups. People will code better when they know they will have to fix their own code when it goes into production. They will care more about stability instead of features. Also, a programmer learns the difference between good and bad coding techniques when they are forced to maintain both. When you are maintaining programs you learn how to right code that is easier to fix or modify later; if all you do is new development you will never learn this key concept.
4 - After the requirements are requested and the specs/design is created don't let users change them. I can't change everything just because a user changes their mind. If I have to change, the release date is pushed back as if I just started the design today. I can't complete a program until you are done knowing what you want it to do.
5 - Procedural vs. Object Orientated programming. The huge developement debate. I admit I am biased toward Procedural programming. However, you should use whatever works better for your project. A GUI works better when you design using OOP, but when you need to crunch numbers on 10 million records procedural will work a lot better. I know a lot has been said about the poor code quality of OOP in particular, but if you get rid of the idiots in #1, the logic should be easy to follow.
6 - KISS - Keep It Simple Stupid - I used to work with someone very intelligent, but his code was terrible. He would program elaborate functions just to add two numbers together. My honest belief is that he tried to impress us with his "coding ability." If someone needs a simple program give them a simple program, don't redesign the wheel.
7 - Shoot and KILL everyone that sponsors or participates in a unreadable source code competition. (sorry personal peeve) We need to promote legible code with indenting and good, clear, and relevant variable naming.
8 - Quality. CMM, ISO, TQI. These are nothing more than BULLSH!T. While there some occasional insights coming from these "Quality" initiatives I disagree with most of the methods. Unfortunately, most of this initiatives are nothing more than feelgood bs for clueless management. Commenting and documenting your code is a good thing. However, these "quality" processes can also cause over-documentation. If you spend more time documenting your code than it will take to rewrite your system, you have documented too much. No one will sit through reading 50 hours of documentation to fix a small bug. When your documentaion helps explains why your code is doing obscure things to save the time of the person after you (or even remind yourself months later) you have the proper level of documentation/comments. I honestly believe that some of these initiatives create tons of documents so consulting/contracting companies can increase billable hours.
9 - Admins and Tech Writers. Hire all the good ones back. The improve our ability to code by letting us
4 - After the requirements are requested and the specs/design is created don't let users change them.
I'd say as an absolute, this is a sure way to get out of business.
I admit that his can be a little extreme; but if we are looking to keep bugs out of code it can be a necessity.
In your example, you talk about building a house. While adding an outlet is generally a simple thing and it may be easy to modify the floorplan for this; The builders will still need to make sure that the electrical system they planned for the house can handle the extra output (possibly having to replace it if not), they will need to check that the new plans are still up to code for the local housing regulations, and they will still need to run new wire to the outlet. Running the new wire is A LOT EASIER if the interior wall are not already in place, and if the house is half built, some walls may alreay be in place. This is need for adding a few simple outlets; think of how this is multiplied
Excellent, I agree with you. I also consider myself an oldbie. (20 years of programming, 12 years being paid for it) Fortunately in the early years I had a teacher that actually emphasize design and comments.
Unfortunately the environment in the business world today prevents truly bug-free programming. A lot needs to change:
1 - Fire all the programmers and developers that can't program. We all know which ones in the group fit into this category. Unfortunately our bosses don't know. They're the ones that cause the majority of the bugs. They came into the industry just for money (pre-2000 bust) and they have no real feel for programming yet they know how to email the boss. Keep the ones that are naturals. The real code warriors. The good ones know when to code new source, when to copy old source, and how to clean up old source when they copy it into their new modules.
2 - Get rid of the bosses that don't know tech people. (i.e. the ones that don't know the difference from #1 above) The boss doesn't need to know tech (it does help) but they do need to know their people. They also need to know how to keep office politics and beauracracy away from their people.
3 - Get rid of separate New Development and Maintenance groups. People will code better when they know they will have to fix their own code when it goes into production. They will care more about stability instead of features. Also, a programmer learns the difference between good and bad coding techniques when they are forced to maintain both.
4 - After the requirements are requested and the specs/design is created don't let users change them. I can't change everything just because a user changes their mind. If I have to change, the release date is pushed back as if I just started the design today. I can't complete a program until you are done knowing what you want it to do.
5 - Procedural vs. Object Orientated programming. The huge developement debate. I admit I am biased toward Procedural programming. However, you should use whatever works better for your project. A GUI works better when you design using OOP, but when you need to crunch numbers on 10 million records procedural will work a lot better. I know a lot has been said about the poor code quality of OOP in particular, but if you get rid of the idiots in #1, the logic should be easy to follow.
6 - KISS - Keep It Simple Stupid - I used to work with someone very intelligent, but his code was terrible. He would program elaborate functions just to add two numbers together. My honest belief is that he tried to impress us with his "coding ability." If someone needs a simple program give them a simple program, don't redesign the wheel.
7 - Shoot and KILL everyone that sponsors or participates in a unreadable source code competition. (sorry personal peeve) We need to promote legible code with indenting and good, clear, and relevant variable naming.
8 - Quality. CMM, ISO, TQI. These are nothing more than BULLSH!T. While there some occasional insights coming from these "Quality" initiatives I disagree with most of the methods. Commenting and documenting your code is a good thing. Unfortunately, most of this initiatives are nothing more than feelgood bs for clueless management.
9 - Admins and Tech Writers. Hire all the good ones back. The improve our ability to code by letting us use admins to do the less technical aspects of our jobs. Their hourly cost is less than ours and by offloading some of our work to them we have more time to develop the system that managent wants done yesterday. This creates more cost effective development even though it raises headcount.
10 - Pay. Simple answer. You get what you pay for. If you offer good pay for good programmers you will get good code in return provided your managers need know their programmers (see #2 above)
11 - Overtime. Don't do it. An overworked, stressed developer is a poor quality developer. A little OT before a release isn't terrible, but 50+ hour weeks for months on end will cause poor code. Also, if a little OT before a release happens, compensate the developer with pay or comp time to make them happy.
12 - TEST TEST TEST TEST TEST TEST. Then test some more. Make sure your users test also. This is the most important step.
I Agree. I am an oldtime gamer now. I want to know what game play enhancements you are creating. I am not interested in how the new version is pretty and uses 3d graphics. What are you doing to the underlying game to get me addicted to it?
I live on the East Coast so please forgive my ignorance of the area. Is this buldge close to Redmond, WA? If so, I would be rooting for the volcano.
Instead of linking to articles, maybe we should just link to prior slashdot posts...
Personally, when I use a fake email address, I use something like bill.gates@microsoft.com. That way I get what I want and Microsoft gets spammed. A win-win situation in my mind. :)
attn: Humorless Moderators: You can mod me as a troll, but I bet most people giggled or plan on trying this the next time they are asked for their email address.
Yes, but that is not all...
Your CPU is cooled by pulling in cool air(relatively speaking) from outside your case and pushing the hotter air out the back. Then the A/C in your house needs to cool the hot air produced by the computer. So you will have to pay more money to run your home's A/C.