Next, they "improve" the "open surface". That is an old microsoft story in a new package. This is FUD, seeding uncertainty on open source and open standards, the fear and doubt are just under the surface. Judging by many of the comments here people are already drinking the cool-aid.
I have done it both ways. The acid test, does it do what it is supposed to, first from my perspective then from user perspective. It is amazing how seeing something work (or not) clarifies the mind. If it does not work then step back take a look and decide what to try next. Sometimes it means starting over again with a very different approach. What I have learned is that the trying things out to see what works and what doesn't it is an integral part of the process. Of course if you already know everything you need to know about the problem then you know the solution and you just do it. This is not so much fun but seems to be what people are hoping to pay for. A good friend of my maintains that the best thing that can happen once you have a new system up and running is a catastrophic disk crash (old school) because then you can start over and you know how to do it properly.
A slight aside; some throw-away code lasts forever, it gets wrapped and re-wrapped because it implements some important functionality need when it was written but is actually more generally useful. Many elaborate carefully planned and executed projects never make it to production because they have somehow missed the window of needfulness. Requirements have changed or were off target from the beginning. Has anyone ever done a system spec'd by higher ups only to find that the people who actually are supposed to it see things very differently? Talk about resistance!
Sometimes I think that the 'suits' will end up destroying the American economy in their pursuit of short term profits at the expense of things like ethics, employee loyalty, the environment, customer loyalty and the middle class.
As interesting as your take on things might be, how do they relate to the engineering task of estimating completion time?
For me, the 'suits' turned the "tractable" problem space I thought I was working in into a slippery quagmire of political decisions and trade offs. That was not what I signed up for and eventually I left. Given the number of basket case projects I have seen, I think that having competent people doing good work in an environment they can count on goes a very long way towards getting reasonable estimates on completion time and resource requirements.
"GOLUB'S LAW OF COMPUTERDOM: A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long."
Seriously, I was once told a project absolutely had to be done on time, within 8 months, and to do what ever I needed to get it done. the previous project had been three times the scheduled completion time. When it was done on time I was slagged for being 10% over a "budget" I had never seen. Fzck the suits! No wonder 80% of "business" is nose to butt.
Slashdot Mirror
Next, they "improve" the "open surface". That is an old microsoft story in a new package. This is FUD, seeding uncertainty on open source and open standards, the fear and doubt are just under the surface. Judging by many of the comments here people are already drinking the cool-aid.
I have done it both ways. The acid test, does it do what it is supposed to, first from my perspective then from user perspective. It is amazing how seeing something work (or not) clarifies the mind. If it does not work then step back take a look and decide what to try next. Sometimes it means starting over again with a very different approach. What I have learned is that the trying things out to see what works and what doesn't it is an integral part of the process. Of course if you already know everything you need to know about the problem then you know the solution and you just do it. This is not so much fun but seems to be what people are hoping to pay for. A good friend of my maintains that the best thing that can happen once you have a new system up and running is a catastrophic disk crash (old school) because then you can start over and you know how to do it properly.
A slight aside; some throw-away code lasts forever, it gets wrapped and re-wrapped because it implements some important functionality need when it was written but is actually more generally useful. Many elaborate carefully planned and executed projects never make it to production because they have somehow missed the window of needfulness. Requirements have changed or were off target from the beginning. Has anyone ever done a system spec'd by higher ups only to find that the people who actually are supposed to it see things very differently? Talk about resistance!
Sometimes I think that the 'suits' will end up destroying the American economy in their pursuit of short term profits at the expense of things like ethics, employee loyalty, the environment, customer loyalty and the middle class.
As interesting as your take on things might be, how do they relate to the engineering task of estimating completion time?
For me, the 'suits' turned the "tractable" problem space I thought I was working in into a slippery quagmire of political decisions and trade offs. That was not what I signed up for and eventually I left. Given the number of basket case projects I have seen, I think that having competent people doing good work in an environment they can count on goes a very long way towards getting reasonable estimates on completion time and resource requirements.
"GOLUB'S LAW OF COMPUTERDOM: A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long." Seriously, I was once told a project absolutely had to be done on time, within 8 months, and to do what ever I needed to get it done. the previous project had been three times the scheduled completion time. When it was done on time I was slagged for being 10% over a "budget" I had never seen. Fzck the suits! No wonder 80% of "business" is nose to butt.