Bill OReilly can't keep left and right straight, much less understand how the hell to deal with pushing Fair Trade instead of Free Trade.
How would an anti-Union, pro-Corporate shill for the right do jack to help the American Worker?
I can't believe this comment got graded "insightful". The reason O'Reilly "can't keep left and right straight" is that he's an independent. He keeps pointing this out but people like you keep not listening. Granted, I think he has a rightward tilt, but he takes the side of the Left sometimes. The main thing he doesn't like is ideology, particularly blind ideology that doesn't let the facts get in the way of it.
Have a sense of humor. O'Reilly isn't running for president (nor will he be), nor is Tammy Bruce. So just give it a rest.
Customers need to realize that software is hardly ever totally bug free. Anyone who tells you that they with absolute certainty write bug-free code is a charlatan trying to bilk you. Good quality software can be achieved, but 100% bug-free is a tall order. So far as I know no testing methodology exists that can say with absolute certainty that a program performs 100% to specification with no flaws.
As I've often said in the past, software development is an art, not a science. Some ask the obvious question, "Then why are there disciplines called 'computer science' and 'software engineering'?" I guess they've never heard of "social science", as in economics... There's an old saying I heard some years back, "Any discipline with the word 'science' in it's name is not a science. It just sounds better with that word added to it." Have you noticed that the true sciences don't have the word "science" in them? Try "physics," "chemistry," "archeology," "geology", etc.
All engineering disciplines have gone through what computer science/software engineering is going through at present. Mechanical Engineering, Electrical Engineering, Civil Engineering. They all went through their early years making advancements, but all the while producing what we'd now call "shoddy work". We can say that now because we know better. Back then people didn't. Even today some engineering disciplines have not totally eliminated bugs. Even today some products, like some cars, have had to be recalled from the market for dangerous design defects.
Someday software will become more measurable and less bug-prone. There will come a time when people will be able to objectively evaluate software quality and even identify all of the bugs and where they're located, before they get to the customer, so they can be fixed. Until then, all we have are brute force methods and ad hoc rules of thumb/best practices that help us avoid some types of bugs. Over time tools have been developed that take some bugs completely out of the equation, but IMO there still are not enough of these tools to completely eliminate them.
I've worked in software consulting my whole career and one of the gripes I've had with it for a long time is the salespeople promise more than can be delivered at a price the customer finds attractive. When you're dealing with a competitive bid process, this seems to always be the case. Since the people they're negotiating with don't understand computers or software completely, not to mention the software development process, the only concrete criteria they have to go on is price and time of delivery. And that's what the salespeople focus on.
Unfortunately this leads to projects that either don't get done because the staff is overworked as it is, before the new project comes along (though I'm a bit doubtfull this is happening these days), or the staff ends up working overtime and weekends to get it done on time, sometimes leading to burnout.
What I've noticed with custom software projects, particularly when they're started from scratch, is they always go over budget. Most projects of this kind are fixed-bid, meaning that the customer pays a lump sum for initial development, and that's all the consulting company gets, until the project gets to a level that is to the customer's satisfaction. Once the customer signs off on it, the maintenance portion of the contract generally kicks in. Given the condition I describe above, this always seems to work to the consulting firm's disadvantage, and creates lots of pressure to get the project done any way you can, even if the code looks like total crap and you would pity the poor soul who has to maintain it after you. My experience has been that so long as the program works, the customer doesn't care about anything else. If one person says they can get it done in a week, and another says they can get it done in a month (for more money), they're going to pick the one who said they could get it done in a week (for less) every time.
What gets me is the complaining about software quality from the customers as though it's all the software providers' fault. I realize the addage that "the customer is always right", but I don't think customers realize they are a part of their own problem, due to their lack of understanding about how the software industry works. I think we'd all be perfectly willing to deliver high quality software, but if I had the opportunity to talk to a customer directly who was wondering how to get it, I'd say, "Don't just jump at the lowest bid you can get. Educate yourself on the best practices in the industry and ask your candidate providers if they're using them. You also need to understand that software development is not a foolproof science. The best results come from taking an extensive amount of time to plan out what you want the software to do as early in the process as possible, and then allow plenty of time at the end of the project for testing and refinement. This leads to much less headaches later on."
I agree with the article's assertion that software providers need to get away from the "not created here" attitude, and be more willing to buy components that can do some of the work for them, to help the project move along more quickly without sacrificing quality. I worked for a firm that had this attitude, and we wrote quite a bit of our own software, which caused projects to run on longer (always past the deadline and overbudget too, to the provider's detriment). Had we bought off-the-shelf components to augment our efforts I'm sure we could've gotten done faster, and spent less money. Organizations often make the erroneous conclusion that because a component or subsystem costs hundreds of dollars, "It's too expensive, we'll just develop it ourselves." Nevermind that paying your developers to do it costs thousands of dollars!
Granted components are not a panacea. The intelligent buyer needs to evaluate them to make sure they aren't buggy, before using them, but it's difficult to argue that this would take more time than developing the same parts in-house.
It's fine for customers to demand better quality, but I think they need to understand what goes into making a better quality product. The one that has the lowest price is not necessarily it.
OMG, yes! I remember this program. At the time (10yo, I think), I didn't even realize what AND and OR gates were, and I was using them to solve the problems.
It's an excellent program.
Yeah I remember that one too. My favorite (in high school) was its sequel: Robot Odyssey, made by the same company, The Learning Company. This game is more advanced. It takes the concept of Rocky's Boots and turns it into an adventure game where you use 4 robots to try to escape from a mysterious underground world. You have to program one or more robots, using logic circuits, to accomplish goals on each level. You use the same principles of AND, OR, and NOT gates, plus flip-flops. I think it eventually gets into the realms of muxes and demuxes as well, but I didn't get that far...
You can find it here. It provides links to download the game, and an Apple II emulator.
I agree that finding an interesting programming language for children can be a challenge these days. Back in the 80s it used to be easy. Programming languages came with the computers, they were simple, and had easy-to-use features that usually allowed access to fun things like graphics and sound. Nowadays, I'd suggest VB. It's not the BASIC we grew up with (with the line numbers, etc.). It's more like Pascal in syntax, plus it has commands for graphics, animation, and sound on Windows. Plus I bet you'd be able to find some easy to follow, beginner programming books for it.
You know the IT sector is screwed when a young guy like me thinks that maybe music is the more profitable career path.
I thought very much along the same lines when I was just coming out of college during the last recession (early 90s). That view of mine got turned around just a year later when I finally found a full-time technical job.
And a word to those who say "the boom times are not coming back" as though that proves what we're experiencing now is just the way it's going to be from now on. I'm not expecting a boom either, but we don't need a boom in order for a recovery in IT to happen. I'd be satisfied with reasonable growth. You have to realize that two years ago the IT industry experienced a 10% decrease in spending, after experiencing 13% increases in spending every year during the boom times. Last year IT spending flatlined, literally. Spending decreased less than 1%. After two years of negative growth in spending, positive growth in spending, which analysts have expected for this year and next, is a good sign!
Hi Apreche. I know what you're going through, because I went through this same thing with the last recession of the early 90s, when I was in college getting my CS degree. Back then I also had lots of trouble finding an internship/co-op position. I heard rumors then that graduate students and those who had been in the private sector for a while were getting these jobs, because the job market was so depressed. I don't think I ever found out if it was true, but that weighed on my mind. It made the job search seem all the more futile. It got to the point that I figured all I was going to amount to, after getting my degree, was stocking shelves or swabbing floors at the local grocery store!
Each year I must've sent out more than 100 resumes seeking an internship, and each year I got at least 1 interview (sometimes a few more), but never getting a position. The picture was pretty bleak for someone who was entry level, with no signs of relief in sight. The job market was pretty bad for at least 2 years.
I graduated in 1993 and didn't get my first full-time technical job until the spring of 1994, with a small local firm of about 10 people. Contrary to what people say is the way to find work, I got the job through a newspaper ad, and sending in my resume (and an interview, of course). By this time people were beginning to feel the economic recovery. My job turned temporary though. I got laid off due to slumping sales, but a few months later I managed to get a contract technical job with another small company, which led to a more secure job later.
The point is, my experience taught me that while things definitely seem tough now (believe me, I feel that too), the situation will improve with time. It's not going to stay like this. I predict that within a few years, if you decide to stick this out, you will be working at a place with a reasonable amount of job security, in a programming position, and that the time you're experiencing now will seem like a distant, unpleasant memory.
Slashdot Mirror
Bill OReilly can't keep left and right straight, much less understand how the hell to deal with pushing Fair Trade instead of Free Trade. How would an anti-Union, pro-Corporate shill for the right do jack to help the American Worker?
I can't believe this comment got graded "insightful". The reason O'Reilly "can't keep left and right straight" is that he's an independent. He keeps pointing this out but people like you keep not listening. Granted, I think he has a rightward tilt, but he takes the side of the Left sometimes. The main thing he doesn't like is ideology, particularly blind ideology that doesn't let the facts get in the way of it.
Have a sense of humor. O'Reilly isn't running for president (nor will he be), nor is Tammy Bruce. So just give it a rest.
Customers need to realize that software is hardly ever totally bug free. Anyone who tells you that they with absolute certainty write bug-free code is a charlatan trying to bilk you. Good quality software can be achieved, but 100% bug-free is a tall order. So far as I know no testing methodology exists that can say with absolute certainty that a program performs 100% to specification with no flaws.
As I've often said in the past, software development is an art, not a science. Some ask the obvious question, "Then why are there disciplines called 'computer science' and 'software engineering'?" I guess they've never heard of "social science", as in economics... There's an old saying I heard some years back, "Any discipline with the word 'science' in it's name is not a science. It just sounds better with that word added to it." Have you noticed that the true sciences don't have the word "science" in them? Try "physics," "chemistry," "archeology," "geology", etc.
All engineering disciplines have gone through what computer science/software engineering is going through at present. Mechanical Engineering, Electrical Engineering, Civil Engineering. They all went through their early years making advancements, but all the while producing what we'd now call "shoddy work". We can say that now because we know better. Back then people didn't. Even today some engineering disciplines have not totally eliminated bugs. Even today some products, like some cars, have had to be recalled from the market for dangerous design defects.
Someday software will become more measurable and less bug-prone. There will come a time when people will be able to objectively evaluate software quality and even identify all of the bugs and where they're located, before they get to the customer, so they can be fixed. Until then, all we have are brute force methods and ad hoc rules of thumb/best practices that help us avoid some types of bugs. Over time tools have been developed that take some bugs completely out of the equation, but IMO there still are not enough of these tools to completely eliminate them.
I've worked in software consulting my whole career and one of the gripes I've had with it for a long time is the salespeople promise more than can be delivered at a price the customer finds attractive. When you're dealing with a competitive bid process, this seems to always be the case. Since the people they're negotiating with don't understand computers or software completely, not to mention the software development process, the only concrete criteria they have to go on is price and time of delivery. And that's what the salespeople focus on.
Unfortunately this leads to projects that either don't get done because the staff is overworked as it is, before the new project comes along (though I'm a bit doubtfull this is happening these days), or the staff ends up working overtime and weekends to get it done on time, sometimes leading to burnout.
What I've noticed with custom software projects, particularly when they're started from scratch, is they always go over budget. Most projects of this kind are fixed-bid, meaning that the customer pays a lump sum for initial development, and that's all the consulting company gets, until the project gets to a level that is to the customer's satisfaction. Once the customer signs off on it, the maintenance portion of the contract generally kicks in. Given the condition I describe above, this always seems to work to the consulting firm's disadvantage, and creates lots of pressure to get the project done any way you can, even if the code looks like total crap and you would pity the poor soul who has to maintain it after you. My experience has been that so long as the program works, the customer doesn't care about anything else. If one person says they can get it done in a week, and another says they can get it done in a month (for more money), they're going to pick the one who said they could get it done in a week (for less) every time.
What gets me is the complaining about software quality from the customers as though it's all the software providers' fault. I realize the addage that "the customer is always right", but I don't think customers realize they are a part of their own problem, due to their lack of understanding about how the software industry works. I think we'd all be perfectly willing to deliver high quality software, but if I had the opportunity to talk to a customer directly who was wondering how to get it, I'd say, "Don't just jump at the lowest bid you can get. Educate yourself on the best practices in the industry and ask your candidate providers if they're using them. You also need to understand that software development is not a foolproof science. The best results come from taking an extensive amount of time to plan out what you want the software to do as early in the process as possible, and then allow plenty of time at the end of the project for testing and refinement. This leads to much less headaches later on."
I agree with the article's assertion that software providers need to get away from the "not created here" attitude, and be more willing to buy components that can do some of the work for them, to help the project move along more quickly without sacrificing quality. I worked for a firm that had this attitude, and we wrote quite a bit of our own software, which caused projects to run on longer (always past the deadline and overbudget too, to the provider's detriment). Had we bought off-the-shelf components to augment our efforts I'm sure we could've gotten done faster, and spent less money. Organizations often make the erroneous conclusion that because a component or subsystem costs hundreds of dollars, "It's too expensive, we'll just develop it ourselves." Nevermind that paying your developers to do it costs thousands of dollars!
Granted components are not a panacea. The intelligent buyer needs to evaluate them to make sure they aren't buggy, before using them, but it's difficult to argue that this would take more time than developing the same parts in-house.
It's fine for customers to demand better quality, but I think they need to understand what goes into making a better quality product. The one that has the lowest price is not necessarily it.
OMG, yes! I remember this program. At the time (10yo, I think), I didn't even realize what AND and OR gates were, and I was using them to solve the problems. It's an excellent program.
Yeah I remember that one too. My favorite (in high school) was its sequel: Robot Odyssey, made by the same company, The Learning Company. This game is more advanced. It takes the concept of Rocky's Boots and turns it into an adventure game where you use 4 robots to try to escape from a mysterious underground world. You have to program one or more robots, using logic circuits, to accomplish goals on each level. You use the same principles of AND, OR, and NOT gates, plus flip-flops. I think it eventually gets into the realms of muxes and demuxes as well, but I didn't get that far...
You can find it here. It provides links to download the game, and an Apple II emulator.
I agree that finding an interesting programming language for children can be a challenge these days. Back in the 80s it used to be easy. Programming languages came with the computers, they were simple, and had easy-to-use features that usually allowed access to fun things like graphics and sound. Nowadays, I'd suggest VB. It's not the BASIC we grew up with (with the line numbers, etc.). It's more like Pascal in syntax, plus it has commands for graphics, animation, and sound on Windows. Plus I bet you'd be able to find some easy to follow, beginner programming books for it.
Good luck.
You know the IT sector is screwed when a young guy like me thinks that maybe music is the more profitable career path.
I thought very much along the same lines when I was just coming out of college during the last recession (early 90s). That view of mine got turned around just a year later when I finally found a full-time technical job.
And a word to those who say "the boom times are not coming back" as though that proves what we're experiencing now is just the way it's going to be from now on. I'm not expecting a boom either, but we don't need a boom in order for a recovery in IT to happen. I'd be satisfied with reasonable growth. You have to realize that two years ago the IT industry experienced a 10% decrease in spending, after experiencing 13% increases in spending every year during the boom times. Last year IT spending flatlined, literally. Spending decreased less than 1%. After two years of negative growth in spending, positive growth in spending, which analysts have expected for this year and next, is a good sign!
Hi Apreche. I know what you're going through, because I went through this same thing with the last recession of the early 90s, when I was in college getting my CS degree. Back then I also had lots of trouble finding an internship/co-op position. I heard rumors then that graduate students and those who had been in the private sector for a while were getting these jobs, because the job market was so depressed. I don't think I ever found out if it was true, but that weighed on my mind. It made the job search seem all the more futile. It got to the point that I figured all I was going to amount to, after getting my degree, was stocking shelves or swabbing floors at the local grocery store!
Each year I must've sent out more than 100 resumes seeking an internship, and each year I got at least 1 interview (sometimes a few more), but never getting a position. The picture was pretty bleak for someone who was entry level, with no signs of relief in sight. The job market was pretty bad for at least 2 years.
I graduated in 1993 and didn't get my first full-time technical job until the spring of 1994, with a small local firm of about 10 people. Contrary to what people say is the way to find work, I got the job through a newspaper ad, and sending in my resume (and an interview, of course). By this time people were beginning to feel the economic recovery. My job turned temporary though. I got laid off due to slumping sales, but a few months later I managed to get a contract technical job with another small company, which led to a more secure job later.
The point is, my experience taught me that while things definitely seem tough now (believe me, I feel that too), the situation will improve with time. It's not going to stay like this. I predict that within a few years, if you decide to stick this out, you will be working at a place with a reasonable amount of job security, in a programming position, and that the time you're experiencing now will seem like a distant, unpleasant memory.