Time will tell. But I doubt it. To do so would be to yield a great deal of the CM, stability, and especially the revenue generation that the platform is known for.
Step 1 is recognizing that your skills have a certain shelf life. Rather than fight it, IT professionals should consider that when planning their careers.
In fact, Vivek Wadhwa believes that colleges should tell computer science and engineering students that "between age 40 and 45 you'll hit your peak, so plan for it."
The issues surrounding transitioning research S/W written by scientists into honest-to-goodness production systems are ones I'm very familiar with.
At my company, a lot of energy has been put into bridging the gap over the years with varying results. I believe that the root cause of the problem is that research S/W is not an end-product; typically for scientists the end-product is a research paper, white paper, proposal paper, etc., for which the S/W is only a tool for getting to the end-product. As soon as the experimental (or proof-of-concept) S/W returns the desired results, the software is considered "done".
In contrast, production S/W is often THE end-product for developers, so a lot more attention is given to robustness, re-usability, etc. All the standard thinking that you want to go into your production S/W.
One big issue for us is that the research S/W is almost always written in Matlab, while the production code is written in C++ and Java. The single largest source of bugs in our systems is porting S/W from Matlab to C++ or Java. (As an aside, please let's not talk about the Matlab 'compiler', nor Octave. -- we've already tried them both, and they're both performance hogs and also create SCM and CM nightmares).
We experimented with requiring that the research S/W be written in C++, but it was a disaster. The scientists couldn't get anything done, and the code was just awful. So, back to Matlab it was.
And, my experience is that people who I have a great deal of respect for, who I consider brilliant in their fields, holding PhD's, etc., have produced the crappiest Matlab code I've ever had the sorrow to read. My favorite instance was the use of these local variable names within a single function of research S/W that was considered "done" (true story): i ii iii iiii iiiii iiiiii
And, of course, little documentation as to the mechanics of the code. And believe me, it gets worse from there. Bear in mind that the code does indeed work for its particular purpose, and may well be ground-breaking in that particular research domain. But "done"? Ready for production? Not without a major porting effort (which is really a re-writing effort). The most mysterious thing to me, though, is that the scientists, for all their intellectual firepower, don't understand that it's a problem.
The solution we've converged on is to require our bizdev to be responsible for funding efforts to rewrite the research code and get it integrated into the product baseline. And, the bizdev types can't proclaim a particular capability "done" (eg., sell it to customers) until they've funded and executed those efforts. It took years of education to get to this point, but things are moving along much better then before.
You:... and I'll need your cost code for this work..... you do have a cost code, don't you? CEO: Fuck the cost code, you figure out one to charge to. Why? Because IT'S YOUR JOB TO FIGURE SHIT LIKE THIS OUT.
You: Is that the Mark 3 or the Mark 4, cos those old Mark 2's well - they're just not up to it... CEO: Oh, well then you'll need to make it work for Marks 2, 3, and 4. Why? Because IT'S YOUR JOB TO FIGURE SHIT LIKE THIS OUT.
You:... need to keep it for a day or two to test the integration... CEO: Fuck that. You'll need to figure out how to do that without using my personal device. Why? Because IT'S YOUR JOB TO FIGURE SHIT LIKE THIS OUT.
Agreed. I just want to get the fucking thing working.
Once the fucking thing is working, I'm done. Ready to hand it off to some janitor, beancounter, or some such other process-loving dweeb. Let them work out all the corner cases and test coverage. That way, I can more quickly move on to some other interesting thing.
Since I live in Austin, not far from the UT campus, I just brought up Google Maps and had a look... and there we are, my wife and me in our front yard. We just happened to be outside when the image was made. I admit to feeling just a bit creeped out.
Anyone who doesn't see this as a problem probably has never really had to deal with configuration management and Q/A issues in a production environment.
I have, and if I were an app developer, this info would scare the crap out of me. Keeping your product stable, repeatable, and traceable on a single platform is hard enough.
When someone offers you a deal that you really don't want, but for whatever reason, you don't want to be seen saying "no" or otherwise turning down business -- then say "yes" to the offer, but make sure that it will be so expensive that the deal is sure to be OBE.
To wit FTA:
The third was a paid product called Site Search, Pond wrote. "The only option for the IFPI/RIAA to access our Web search API will be the third option," Pond wrote, according to the source who had seen the letter. "I understand we charge a standard rate of $5 per thousand queries, which is charged to recover our costs in providing this service," Pond wrote. A music industry source estimated that such charges could add up to several million dollars a year.
Slashdot Mirror
...is that there's so many to choose from!
If your company has an "IT Department", then the company too large. It is time to quit and go work for a smaller company.
I'm not touching the stuff until
FTA: Smartphones and tablets are nothing more than computers, ...
Nope. They're appliances . People just want to turn them one and use them.
My understanding is that applications won't be able to see other users's files.
Sounds like UNIX to me. And, gee, that's been around for only 40 years.
Time will tell. But I doubt it. To do so would be to yield a great deal of the CM, stability, and especially the revenue generation that the platform is known for.
FTA: That means JavaFX is now supported on any device that offers a JVM.
Bzzt. Thanks for playing. There is one extremely important class of device that does not and will not ever offer a JVM.
When referring to a vehicle manufactured by BMW, the following rules should be used:
2 wheels: "Beamer"
4 wheels: "Bimmer"
FTA:
Thanks! I'll be looking closely at Armadillo.
... the elimination of advanced GUI administration tools...
Incorrect. Lion does indeed include the most awesome GUI administration tool in existence.
It's called Terminal.
The issues surrounding transitioning research S/W written by scientists into honest-to-goodness production systems are ones I'm very familiar with.
At my company, a lot of energy has been put into bridging the gap over the years with varying results. I believe that the root cause of the problem is that research S/W is not an end-product; typically for scientists the end-product is a research paper, white paper, proposal paper, etc., for which the S/W is only a tool for getting to the end-product. As soon as the experimental (or proof-of-concept) S/W returns the desired results, the software is considered "done".
In contrast, production S/W is often THE end-product for developers, so a lot more attention is given to robustness, re-usability, etc. All the standard thinking that you want to go into your production S/W.
One big issue for us is that the research S/W is almost always written in Matlab, while the production code is written in C++ and Java. The single largest source of bugs in our systems is porting S/W from Matlab to C++ or Java. (As an aside, please let's not talk about the Matlab 'compiler', nor Octave. -- we've already tried them both, and they're both performance hogs and also create SCM and CM nightmares).
We experimented with requiring that the research S/W be written in C++, but it was a disaster. The scientists couldn't get anything done, and the code was just awful. So, back to Matlab it was.
And, my experience is that people who I have a great deal of respect for, who I consider brilliant in their fields, holding PhD's, etc., have produced the crappiest Matlab code I've ever had the sorrow to read. My favorite instance was the use of these local variable names within a single function of research S/W that was considered "done" (true story):
i
ii
iii
iiii
iiiii
iiiiii
And, of course, little documentation as to the mechanics of the code. And believe me, it gets worse from there. Bear in mind that the code does indeed work for its particular purpose, and may well be ground-breaking in that particular research domain. But "done"? Ready for production? Not without a major porting effort (which is really a re-writing effort). The most mysterious thing to me, though, is that the scientists, for all their intellectual firepower, don't understand that it's a problem.
The solution we've converged on is to require our bizdev to be responsible for funding efforts to rewrite the research code and get it integrated into the product baseline. And, the bizdev types can't proclaim a particular capability "done" (eg., sell it to customers) until they've funded and executed those efforts. It took years of education to get to this point, but things are moving along much better then before.
Well, that's a bummer.
I just started using Google Body a couple of months ago, and it's fantastic.
Especially if you're about to have shoulder surgery.
Don't want to see this site disappear...
A piece of black tape over the camera.
We're moving back to make. Full disclosure: it was my idea to move to scons in the first place. Dammit.
You: ... and I'll need your cost code for this work ..... you do have a cost code, don't you?
CEO: Fuck the cost code, you figure out one to charge to. Why? Because IT'S YOUR JOB TO FIGURE SHIT LIKE THIS OUT.
You: Is that the Mark 3 or the Mark 4, cos those old Mark 2's well - they're just not up to it ...
CEO: Oh, well then you'll need to make it work for Marks 2, 3, and 4. Why? Because IT'S YOUR JOB TO FIGURE SHIT LIKE THIS OUT.
You: ... need to keep it for a day or two to test the integration...
CEO: Fuck that. You'll need to figure out how to do that without using my personal device. Why? Because IT'S YOUR JOB TO FIGURE SHIT LIKE THIS OUT.
Remember the "precedent" where record companies had exclusive rights to distribute recorded music?
The Congress is about to discover the same lesson regarding technology that refuses to be regulated.
Agreed. I just want to get the fucking thing working.
Once the fucking thing is working, I'm done. Ready to hand it off to some janitor, beancounter, or some such other process-loving dweeb. Let them work out all the corner cases and test coverage. That way, I can more quickly move on to some other interesting thing.
initscripts. If you're not writing them, you aren't a software developer.
But companies that use such programs spend more on such things as learning to use them and making them work with other software
This says a lot more about the intelligence of the company's employees than it does about the software.
Dang! Out of mod points! Anyone who's developing thick-client GUIs in this day and age is a fool.
Since I live in Austin, not far from the UT campus, I just brought up Google Maps and had a look ... and there we are, my wife and me in our front yard. We just happened to be outside when the image was made. I admit to feeling just a bit creeped out.
Anyone who doesn't see this as a problem probably has never really had to deal with configuration management and Q/A issues in a production environment.
I have, and if I were an app developer, this info would scare the crap out of me. Keeping your product stable, repeatable, and traceable on a single platform is hard enough.
When someone offers you a deal that you really don't want, but for whatever reason, you don't want to be seen saying "no" or otherwise turning down business -- then say "yes" to the offer, but make sure that it will be so expensive that the deal is sure to be OBE.
To wit FTA:
The third was a paid product called Site Search, Pond wrote. "The only option for the IFPI/RIAA to access our Web search API will be the third option," Pond wrote, according to the source who had seen the letter.
"I understand we charge a standard rate of $5 per thousand queries, which is charged to recover our costs in providing this service," Pond wrote.
A music industry source estimated that such charges could add up to several million dollars a year.
Ed, man!
!man ed
http://www.gnu.org/fun/jokes/ed.msg.html