Exactly, I wasn't going to bring Jobs up, but he was the designer and ultimate decider of what went into a system. Unfortunately, very very few designers can actually do this. But, he still gathered a list of requirements for the teams to develop:)
I'm not sure where you got that one from? Users don't write specifications for software, a designer somewhere does. In fact, you support that with "The rest of the industry has found out that users in general don't know what they want" which is just all the more reason to not let them specific requirements. After all, what you want won't be what someone else wants. Someone needs to do the analysis of what they actually need. That's called requirements gathering. It actually takes significant time and effort in many cases.
...Within the project's lifetime the whole way in which people used and viewed websites changed completely.
Really? Everything changed? Did HTTP(S) disappear? Did TCP go away? Did HTML vanish? Is javascript no longer used for dynamic web content? Guess what - all of those things are still current today, and still work today. What doesn't are vendor specific items like IE6, and if you were developing specifically for that, well, then you made a terrible choice, especially if it affected your entire application stack.
If you think everything can be foreseen at project conception, then you know literally zero about the realities of software development.
So apparently, the only thing that needed changing in your case was the GUI. If you knew squat about web development, that would have been a relatively minor thing to change, provided that you knew what you were doing in the first place. Building to IE6 indicates otherwise however.
You would literally need someone who can see the future on your team to be able to do what you're claiming successfully and consistently.
No, what I need to be able to do is take technology today, as it exists, pick the proper components, even if they are alpha/beta, and ensure that my choices are kept up to date and do what they need to do, especially in the alpha/beta area. It's called tracking your dependencies, and it's not accomplished by tying yourself to maven central.
Government IT projects are universally known to be a complete joke, precisely because the failure rate is astoundingly high.
What's funny is I was involved in a rather large successful gov IT project. The problem with the failure rate is the same as it is everywhere else - bad management and/or incompetence. Add something like Agile and you can just write it off before you start.
"Having been exposed to a number of Agile projects that all ran over budget, schedule and/or failed, I can truthfully say Agile itself was the cause."
Oh not this old chestnut. This doesn't even make sense, the whole point in an agile project over waterfall is that it cannot run over budget or beyond schedule. The whole point is that you keep sprinting until you've spent as much as you want to spend for the deliverable provided at the end of each sprint.
Have you worked in the real world? Generally a project is envisioned, then estimated and budgeted. This happens at the beginning of a project, because generally shareholders (public companies) don't like to spend 50M on a project (promised functionality) and not receive a working model. Take the car analogy, GM is going to design a new car, they're budgeting 'x' for it based on previous history, and 'y' time. This will get it out on date 'z', per the normal car release schedule (once a year) Investors like the new concept, and eagerly await the production run to produce this new wonder. However, for this project, GM departs from their tried and true process, and incorporates Agile. They start work, the teams are too large, scrums eat far too much time so they segment the teams to stay on schedule. As things segment, communication starts to whither, because no one is managing the full project. Stakeholder see the frame, the new engine, etc taking shape per schedule, and decide that a minor change here and there will improve things. It comes time to integrate once the prototypes are designed and built. Gee, those 2 disparate changes now cause the engine not to mount to the frame, and the controls require rewiring because the harness doesn't match up. Now there's a mad scramble, the prototype doesn't make its date, the car isn't built and slips into next year. Stock plunges.
But some of what you say in your zeal to defend waterfall is just complete and utter nonsense because waterfall, like agile, is not a silver bullet either.
Historical revisionism runs rampant in the Agile crowd. Do recall that Agile started with XP programming, more or less, and when that failed (to get traction, produce results, any other measure you care to name) they started slapping additional things on top of it. It has morphed so much over the years that you have to pretty much specify the year and methodology du jour to know whether a project was "Agile" at that time. "Agile" is a failed "methodology", if you can even call something so ambiguous a methodology, and is just code for "we don't like being told what to do or take any responsibility for the results of the project". I'm the polar opposite of that, I take a project and intend to deliver it within specs, on time, and on budget. I generally succeed.
You might want to talk to NASA and tell them all their missions have failed.
1. All the descions are taken at the time you know the least about the outcome, ie at the begining.
You know what that's a sign of? Failure to specify your requirements. (Something Agile people know so little of these days it's unsurprising they should be banned from programming)
2. By the time you get to the end your requirements are out of date, you get the product you wanted at the start of the project not the one you need now.
I need what I specified. If I need something else now, I should have added on more requirements. In fact, at the start of the project I should have added in an allowance that just maybe I will need to change something, or a dependency in the project may shift in time or not meet its capabilities. BTW, for you Agile people, this is where the Project Manager usually does his work. If they're managing which requirement you're coding and how, he's not doing his job.
If you try to support requirement change all you end up doing is replanning and pushing back delivery.,
If I was originally scheduled to make a simple sort in an adequate time period and then need to add in a complex multi-layered sort, um, yeah? What makes you think changed requirements wind up being deliverable in the same time frame? What vacuum do you live in? Are there pink ponies there too?
3. It was a failed methodology from the start, the original paper that started waterfall was an example of how not to write software
Again, I guess you better let all gov agencies know that all their projects involving software prior to 2005 or so failed. Guess that moon landing really was on a stage somewhere.
Having been exposed to a number of Agile projects that all ran over budget, schedule and/or failed, I can truthfully say Agile itself was the cause. I've detailed some of those elsewhere, and the response from the believers is always "Oh, you're doing it wrong" which is hilarious, because in multiple cases they were following exactly what little is laid out by the Agile camp. The real truth is that there are developers of different skills, and there are some that excel in specific areas while the rest plod along, and they are not interchangeable like Agile states they are unless you're going LCD. In fact, if you estimate your "velocity" by your worst performing programmer on an Agile team, you may, just may, have a realistic estimate of when you'll supposedly get to the finish line as long as no one throws any new requirements your way. As soon as they do, everything you think you know just went away. Sorry, my next SCRUM is pulling me out of this one...
A company designs and builds a car to safely drive at 70 mph.
You drive at 140mph in the rain, hydroplane and lose control hitting a bridge column, and die. I'd say the fault lies with the driver. What about you?
Said company puts in an ignition switch that's faulty and disconnects the entire control system while driving at 70mph and ignores reports of this problem for a decade. That would not only be the fault of said company, but adds layers of premeditation still to be decided.
You know, if RoR was ever more than a splash in the history of time, maybe someone would have cared more about Rust. Somehow, being "rusty" just doesn't seem to go with hipster, geek, ninja, or rockstar.
This was across multiple companies, just pointing to the fact that many companies fail in this area. I will say I have yet to see 1 successful project that succeeded with large numbers of H1Bs, or any outsourcing project, in many many years.
I've worked with dozens, perhaps hundreds of above average people who have the opportunity to become the best in the future because they were brought here on H1-Bs.
And I have worked with hundreds of far below average H1-Bs. In fact, I'd be happy to have stated I worked with a handful of average H1-Bs, but that's not happened. So what? It's anecdotal, until there's an overwhelming set of anecdotes about the lack of above average H1-Bs with almost 0 supporting that case.* I'm sure it happens, but it's an exception rather than the rule. And given that they are average, there's no reason you can't hire an average american to work instead. Until that is handled, there's no reason to bring in more H1-Bs.
* - note that it is still anecdotal until someone actually does a decent study to determine the actual reality.
The best of us compete well. The average to just below the best have challenges, and they are the ones being replaced by H1Bs and other modes of "ditching American workers", because sweatshop wages are what they are. It's hard to replace the artist, but easy to replace the brush cleaner. What those that are doing this are not seeing for the next quarters profit report is that by not training any of the average to above average people, they're significantly reducing the pool of those that potentially could become the best in the future.
I guarantee you it doesn't cost double the cost of a pound of rice to ship rice, not even close. I can ship a 4000 pound vehicle overseas for $600, which works out to about $0.15 per pound, and is considerably more valuable and fragile and possibly larger than 4000 pounds of rice. So I call BS on that.
As long as people can live on less than 1/2 the wages in these areas, the US workforce will never be able to compete. For instance, a pound of rice or a loaf of bread costs less than $0.50. And when you consider that they're comparing equivalent lifestyles, not the average lifestyle in each area, that wage disparity grows even larger. Now, in a truly global economy, we (US folks) would buy up all this cheap rice instead of our very expensive rice. Why doesn't this happen? Because we're not in a global economy, obviously.
Having just started looking into this, it appears that the "cheaper better imports" are actuallyheavily subsidized. If you're going to complain about things, make sure to get the entire picture in there, especially when it's highly relevant to one of your main points.
They'll work at Starbucks, though. But yes, earlier on we took whatever we could get as a job. Parents weren't giving you a free ride (or mine didn't) and I worked from high school on. Paper routes, mowing grass and taking care of yards, etc. Working fast food. None of those jobs around me are done by your average teen.
Hahahahaha. Productivity, sure, that's what technology means but harder? Longer hours? Do you even history?
Yes I do, do you know how to count?
I do, and subtracting 5 hours of facebook/twitter/starbuck's swilling cooler time from the "9" hours they're in the office....
Oh, nevermind, I guess you don't. The Great Depression saw some of the most far reaching and ambitious public works projects in modern history as well as an equally staggering reform of wall street. This "recession" sees people like you claiming there's no problem and people just need to work harder.
It also saw long bread lines, sell your body for a day labor lines, and working for peanuts handouts in those government programs because peanuts were better than nothing. As for reforming wall street, I wish we'd not forgotten those lessons. We can all thank Reagan for starting the unravelling of those reforms in the 80s. I guess he "forgot" why they were needed.
You and everyone that followed is correct, if you shoot, you should shoot to kill. I was still in the mindset of them killing this mentally ill guy with a knife. I should have left that sentence out.
And then the other 90% is actually writing the code and testing the integration. Anyone that thinks 80% of IT happens away from the code/editor isn't in development.
Slashdot Mirror
as does speling
Exactly, I wasn't going to bring Jobs up, but he was the designer and ultimate decider of what went into a system. Unfortunately, very very few designers can actually do this. But, he still gathered a list of requirements for the teams to develop :)
I'm not sure where you got that one from? Users don't write specifications for software, a designer somewhere does. In fact, you support that with "The rest of the industry has found out that users in general don't know what they want" which is just all the more reason to not let them specific requirements. After all, what you want won't be what someone else wants. Someone needs to do the analysis of what they actually need. That's called requirements gathering. It actually takes significant time and effort in many cases.
I thought it was about successful software projects, not unique interchangeable snowflakes. Perhaps that's where Agile went wrong.
...Within the project's lifetime the whole way in which people used and viewed websites changed completely.
Really? Everything changed? Did HTTP(S) disappear? Did TCP go away? Did HTML vanish? Is javascript no longer used for dynamic web content? Guess what - all of those things are still current today, and still work today. What doesn't are vendor specific items like IE6, and if you were developing specifically for that, well, then you made a terrible choice, especially if it affected your entire application stack.
If you think everything can be foreseen at project conception, then you know literally zero about the realities of software development.
So apparently, the only thing that needed changing in your case was the GUI. If you knew squat about web development, that would have been a relatively minor thing to change, provided that you knew what you were doing in the first place. Building to IE6 indicates otherwise however.
You would literally need someone who can see the future on your team to be able to do what you're claiming successfully and consistently.
No, what I need to be able to do is take technology today, as it exists, pick the proper components, even if they are alpha/beta, and ensure that my choices are kept up to date and do what they need to do, especially in the alpha/beta area. It's called tracking your dependencies, and it's not accomplished by tying yourself to maven central.
Government IT projects are universally known to be a complete joke, precisely because the failure rate is astoundingly high.
What's funny is I was involved in a rather large successful gov IT project. The problem with the failure rate is the same as it is everywhere else - bad management and/or incompetence. Add something like Agile and you can just write it off before you start.
"Having been exposed to a number of Agile projects that all ran over budget, schedule and/or failed, I can truthfully say Agile itself was the cause."
Oh not this old chestnut. This doesn't even make sense, the whole point in an agile project over waterfall is that it cannot run over budget or beyond schedule. The whole point is that you keep sprinting until you've spent as much as you want to spend for the deliverable provided at the end of each sprint.
Have you worked in the real world? Generally a project is envisioned, then estimated and budgeted. This happens at the beginning of a project, because generally shareholders (public companies) don't like to spend 50M on a project (promised functionality) and not receive a working model. Take the car analogy, GM is going to design a new car, they're budgeting 'x' for it based on previous history, and 'y' time. This will get it out on date 'z', per the normal car release schedule (once a year) Investors like the new concept, and eagerly await the production run to produce this new wonder. However, for this project, GM departs from their tried and true process, and incorporates Agile. They start work, the teams are too large, scrums eat far too much time so they segment the teams to stay on schedule. As things segment, communication starts to whither, because no one is managing the full project. Stakeholder see the frame, the new engine, etc taking shape per schedule, and decide that a minor change here and there will improve things. It comes time to integrate once the prototypes are designed and built. Gee, those 2 disparate changes now cause the engine not to mount to the frame, and the controls require rewiring because the harness doesn't match up. Now there's a mad scramble, the prototype doesn't make its date, the car isn't built and slips into next year. Stock plunges.
But some of what you say in your zeal to defend waterfall is just complete and utter nonsense because waterfall, like agile, is not a silver bullet either.
And thi
It was called project management. :)
Historical revisionism runs rampant in the Agile crowd. Do recall that Agile started with XP programming, more or less, and when that failed (to get traction, produce results, any other measure you care to name) they started slapping additional things on top of it. It has morphed so much over the years that you have to pretty much specify the year and methodology du jour to know whether a project was "Agile" at that time. "Agile" is a failed "methodology", if you can even call something so ambiguous a methodology, and is just code for "we don't like being told what to do or take any responsibility for the results of the project". I'm the polar opposite of that, I take a project and intend to deliver it within specs, on time, and on budget. I generally succeed.
Wait... what!?
You obviously don't know what you are talking about.
I certainly must not which must be why I was rated troll -5 and you felt the need to respond with a lot of nothing.
(blah blah blah) Why do you think "individuals" is the very first word ...
Because it sounds good?
Waterfall just cannot work.
You might want to talk to NASA and tell them all their missions have failed.
1. All the descions are taken at the time you know the least about the outcome, ie at the begining.
You know what that's a sign of? Failure to specify your requirements. (Something Agile people know so little of these days it's unsurprising they should be banned from programming)
2. By the time you get to the end your requirements are out of date, you get the product you wanted at the start of the project not the one you need now.
I need what I specified. If I need something else now, I should have added on more requirements. In fact, at the start of the project I should have added in an allowance that just maybe I will need to change something, or a dependency in the project may shift in time or not meet its capabilities. BTW, for you Agile people, this is where the Project Manager usually does his work. If they're managing which requirement you're coding and how, he's not doing his job.
If you try to support requirement change all you end up doing is replanning and pushing back delivery.,
If I was originally scheduled to make a simple sort in an adequate time period and then need to add in a complex multi-layered sort, um, yeah? What makes you think changed requirements wind up being deliverable in the same time frame? What vacuum do you live in? Are there pink ponies there too?
3. It was a failed methodology from the start, the original paper that started waterfall was an example of how not to write software
https://pragtob.wordpress.com/...
Again, I guess you better let all gov agencies know that all their projects involving software prior to 2005 or so failed. Guess that moon landing really was on a stage somewhere.
Having been exposed to a number of Agile projects that all ran over budget, schedule and/or failed, I can truthfully say Agile itself was the cause. I've detailed some of those elsewhere, and the response from the believers is always "Oh, you're doing it wrong" which is hilarious, because in multiple cases they were following exactly what little is laid out by the Agile camp. The real truth is that there are developers of different skills, and there are some that excel in specific areas while the rest plod along, and they are not interchangeable like Agile states they are unless you're going LCD. In fact, if you estimate your "velocity" by your worst performing programmer on an Agile team, you may, just may, have a realistic estimate of when you'll supposedly get to the finish line as long as no one throws any new requirements your way. As soon as they do, everything you think you know just went away. Sorry, my next SCRUM is pulling me out of this one...
I'm assuming your next Yaris will come this way?
A company designs and builds a car to safely drive at 70 mph.
You drive at 140mph in the rain, hydroplane and lose control hitting a bridge column, and die. I'd say the fault lies with the driver. What about you?
Said company puts in an ignition switch that's faulty and disconnects the entire control system while driving at 70mph and ignores reports of this problem for a decade. That would not only be the fault of said company, but adds layers of premeditation still to be decided.
You know, if RoR was ever more than a splash in the history of time, maybe someone would have cared more about Rust. Somehow, being "rusty" just doesn't seem to go with hipster, geek, ninja, or rockstar.
man, what are you smoking? ... Now, if you're going to argue C that was compiled with a C++ compiler,
You better pass some of that.... C++ compiled with a C compiler after going through a transformation, sure.
This was across multiple companies, just pointing to the fact that many companies fail in this area. I will say I have yet to see 1 successful project that succeeded with large numbers of H1Bs, or any outsourcing project, in many many years.
Sounds more like Microsoft got into the Linux world.
I've worked with dozens, perhaps hundreds of above average people who have the opportunity to become the best in the future because they were brought here on H1-Bs.
And I have worked with hundreds of far below average H1-Bs. In fact, I'd be happy to have stated I worked with a handful of average H1-Bs, but that's not happened. So what? It's anecdotal, until there's an overwhelming set of anecdotes about the lack of above average H1-Bs with almost 0 supporting that case.* I'm sure it happens, but it's an exception rather than the rule. And given that they are average, there's no reason you can't hire an average american to work instead. Until that is handled, there's no reason to bring in more H1-Bs.
* - note that it is still anecdotal until someone actually does a decent study to determine the actual reality.
The best of us compete well. The average to just below the best have challenges, and they are the ones being replaced by H1Bs and other modes of "ditching American workers", because sweatshop wages are what they are. It's hard to replace the artist, but easy to replace the brush cleaner. What those that are doing this are not seeing for the next quarters profit report is that by not training any of the average to above average people, they're significantly reducing the pool of those that potentially could become the best in the future.
My guess is they do exactly this, because if they didn't, there would be large numbers of reports of data corruption.
I guarantee you it doesn't cost double the cost of a pound of rice to ship rice, not even close. I can ship a 4000 pound vehicle overseas for $600, which works out to about $0.15 per pound, and is considerably more valuable and fragile and possibly larger than 4000 pounds of rice. So I call BS on that.
As long as people can live on less than 1/2 the wages in these areas, the US workforce will never be able to compete. For instance, a pound of rice or a loaf of bread costs less than $0.50. And when you consider that they're comparing equivalent lifestyles, not the average lifestyle in each area, that wage disparity grows even larger. Now, in a truly global economy, we (US folks) would buy up all this cheap rice instead of our very expensive rice. Why doesn't this happen? Because we're not in a global economy, obviously.
Having just started looking into this, it appears that the "cheaper better imports" are actuallyheavily subsidized. If you're going to complain about things, make sure to get the entire picture in there, especially when it's highly relevant to one of your main points.
They'll work at Starbucks, though. But yes, earlier on we took whatever we could get as a job. Parents weren't giving you a free ride (or mine didn't) and I worked from high school on. Paper routes, mowing grass and taking care of yards, etc. Working fast food. None of those jobs around me are done by your average teen.
Hahahahaha. Productivity, sure, that's what technology means but harder? Longer hours? Do you even history?
Yes I do, do you know how to count?
I do, and subtracting 5 hours of facebook/twitter/starbuck's swilling cooler time from the "9" hours they're in the office....
Oh, nevermind, I guess you don't. The Great Depression saw some of the most far reaching and ambitious public works projects in modern history as well as an equally staggering reform of wall street. This "recession" sees people like you claiming there's no problem and people just need to work harder.
It also saw long bread lines, sell your body for a day labor lines, and working for peanuts handouts in those government programs because peanuts were better than nothing. As for reforming wall street, I wish we'd not forgotten those lessons. We can all thank Reagan for starting the unravelling of those reforms in the 80s. I guess he "forgot" why they were needed.
Why do you think you deserve to be rich?
You and everyone that followed is correct, if you shoot, you should shoot to kill. I was still in the mindset of them killing this mentally ill guy with a knife. I should have left that sentence out.
And then the other 90% is actually writing the code and testing the integration. Anyone that thinks 80% of IT happens away from the code/editor isn't in development.