"The problem is it wasn't incurred against the electorates wishes, they didn't want to have their taxes raised and they didn't want to lose state benefits or services."
Are you aware that this takes all the "war effort" out of the equation?
Maybe, just maybe, the electorate could have their taxes not raised and the state benefits sustained if just USA government didn't push itself on a war-related expending galore.
So this Prof. Tim Murphy just has rediscovered Malthus... and it only took him 200 years. Wow!
Re:Data, Images, Binary builds etc.
on
The Rise of Git
·
· Score: 1
"Hmm "data, images, other binaries" - nope, not seeing anything looks like source code to me."
Source is anything you need to start with in order to produce your deliverables.
For some people is just a bunch of text files. For other people is a bunch of text files plus a bunch of images. And, then, for another people is a bunch of text files plus a bunch of images plus a bunch of binary blobs. It all depends on your requirements*1.
"Don't know why you'd want to version binary data"
In order to be able to re-produce past releases, of course. I.e.: my product depends of my source code, some embedded images from my art department and some third party libraries I recieve as binary blobs.
Of course I could reinvent the wheel and produce my own in-house history control system but then, why would I *want* to do that unless -as it is the case, because of the inability of the SCM tool? Time and again people has been bitten by the "binaries within the SCM" problem but it has always been because the inability of the tool, not because having binaries as part of the sources didn't make sense.
"line by line diff doesn't work to well on them"
That's not the be-it-all of diffing. I may want to produce foo 1.2.3 to diff its *behaviour* against foo 4.5.6 to see when a bug was introduced. If my operational definition for "foo 1.2.3" includes something on the lines of "and the version of library bar that was used back then", so be it.
"and there's always backups"
Repeat with me: a backup, is a backup, is a backup and it is by no means a historical storage solution. A backup is (part of) the tool you use to recover your system to as near as possible a state after a failure. It has absolutly *nothing* to do with helping to your product delivery process and expecting it is as big a mistake as, say, thinking that RAID is a substitute for backups.
"I've personally never seen the point of versioning or backing up autogenerated data"
1) There can be other binaries apart from your own autogenerated data. 2) If there's the chance you won't be able to produce again in the future the same autogenerated data, then whatever you need to do it you should treat as source too (i.e., if foo 1.2.3 must be compiled with gcc 2.95.17, then you need to store gcc 2.95.17, tie it to the corresponding version of your sources and track the evolution of such correspondencies along time, be it within the SCM or not -of course, much the better if you can do it within a one single tool).
*1 For the most extreme case it might be source, binaries *and* blueprints *and* hardware, i.e. an ICBM guide and control system or a core banking solution. My requirements may include the ability to reproduce it from the ground up at any moment in the next 30 to 50 years. Of course I can't introduce some past model of a vacuum lamp in the SCM but again, it is not that I wouldn't want to do it (of course I would want to do something on the lines of `scm checkout --date 19700301 thewholesystem`) but that I can't (in this case both because of limitations of the tool *and* limitations of the physical world).
No. What he says is that luck is what makes the difference. A lot of people come with good ideas, hard word and even enough capital but only a few success. What's the difference between the ones and the others?
"The zero is not a significant digit, as a trailing zero with no subsequent non-zero values, and no decimal point after it."
So what you are saying is that the "nobody shall live longer than 120 years" is not an assertion but the measure of an empiric experiment? And that such experiment was unable to measure longevity with better precision than a decade? It this what you are saying? Because if that's not what you are saying I regretfully must say that you are miserably wrong.
"The problem is not that it's their job to accomplish this, it's the scientists saying "but the code is already written, you don't have much work to do" when this is, in fact, not true."
Of course is not. Nor it is (usually) among the scientist's abilities to to lead and valuate a software project effort. No news here.
"The further problem becomes when other people listen to the scientist and get unrealistic expectations of how long it will take for a product, which can be sold, to be ready."
While not a surprise this says nothing about the scientist but about the managerial abilities about the one believing nonsenses.
It is hardly the fault of the one obviously not knowing what's saying to say nonsenses but the fault of the one believing him when his job is to know better.
I'll say it again. There's no debt if there's no intention to repay it (or if, in fact, it is not repayed).
When you incur in a debt you have to repay the principal and the interests. If the code does all that needs to be done, then there's absolute nothing you will have to repay and it is not the case that the interest rate is low but that there is no technical debt *at all*.
On the other hand, if you -or others, happen to reuse the code in the future (but note the *if*) then there will be the case that certainly you will have to pay all you didn't pay before in the form of design or documentation *even* if it is you yourself the one modifying the original code (while certainly the interest rate for your own code will probably be less than that of a third party one, since then you'll have at least a bit of documentation: your own memories).
And here comes the point: the referenced article was talking about "a piece of research software [that] is suddenly expected to be ready for production", that is, a piece of code that never was meant to be used in production for third parties but all of a sudden *someone* which is not the original author, decides it can produce further benefits if productized.
Therefore there was no debt, what it is now is the need of further investment. For a different analogy, imagine you buy your home, just for you, your husband or wife and your two children and then, your boss decides that he will come to live with you and, by the way, to open a new office for ten people on the premises. Would you think you incurred in any kind of debt by buying a 300.000$ house instead of a 1.000.000$ building or is it the case that *for the new scenario* a new investment of 700.000$ is needed?
Expending more time and effort than needed up-front just in case is not covering (or not incurring) a debt, is just throwing resources away.
The "technical debt" concept is all well and good for productivity software (either in-house or meant to be sold away) and it is in fact a concept that quite a lot of directors if not managers should have continously present (and I purpousely am telling "directors if not managers" because I've sadly known quite a lot of managers perfectly aware of the concept but, as I said, there's not debt if there's no intention to repay it -I'll be far away when the shit hits the fan, they think) but still it is needed to understand when it's a valid concept and when it is not.
""Technical Debt". Your quick-n-dirty code that does what you need it to do carries a great deal of technical debt, but the nature of its limited use means the interest payments are small"
You seem to forget that the basic tenet on "technical debt" is "debt". There's not debt if there's no expectancy of having to repay it.
Which holds true for most of one-shoot code that scientists produce.
On the other hand, it might happen that some of the one-shoot code produced is seen as something of value by something else (may it be someone in management?). Then is up to said third party to pay what he sees as debt, not the one for whom the code already produced all that has to be done. In other words: if I am the scientist one coding my dirty hack for my own purpouses don't expect being me the one doing all that needs to be done on top of the special case code around an algorithm to evolution my dirty hack into your shinny product.
Then the scientist developed the code exactly to the point that brings him what he needs. That's good engineering practice, isn't it?
"It's another thing to be able to use it outside the original group that created it and another thing entirely to turn it into something that can be used by someone who wants to use the functionality for a completely different task."
Which if any, it is your jobs, not hims, to acomplish.
"I'm working on commercializing NASA software and this couldn't be more true."
I don't think is just NASA. Wasn't an IBM engineer the one that said: X time for a valid prototype; 10*X for an in-house product; 100*X for a commercial packaged application?
Given that what a scientist does for her calculations is in the "valid prototype" stage (why the hell would she be interested in anything else?) you can do the math about how much it will cost to put it on a shelf, so to say.
"if "120 years" didn't express what two significant digits does as a matter of basic math"
Well, it's obvious that 120 is *three* significant digits: the one, then the two and finally the zero. There's no magic in the ending zero and 120 is not "about twelve tens"; it is "one hundred and twenty".
On the other hand, there's nothing "scientific" about 120 being somewhere between 119.6 and 120.5 it is about the theory of measure.
Unless you don't have the confidence that the one telling "nobody older that 120 years" was able to count by the year and its ability only reached to count by the tens of years (or the century, or the millenia), 120 years is not even "somewhere between 119 and six months to 120 and six months" but exactly meaning "by their 120 birthday". And if it's an universal law -and that's it is in fact science, a single example is more than enough to shake the whole theory. Nobody over 120 years means no f* body, no exceptions, just like Einstein's theory would be under heavy problems if there were just *one* case of something going over C in vacuum ("well, that's 99.999999% accuracy" wouldn't make a case).
For the same reason they don't debate if cars run over four wheels or if fire is hot or not.
Because it's such an obvious fact to any minimally educated person that being for debate is a terryifically worrying symptompt of a very bad situation.
"Texas has yet to decide on the existeance gravity."
Well, every family has to have the option to decide how to teach their children and what their believes are, so they should have to have the option to teach alternate views about gravity.
After all is not as if you can prove gravity since you never saw it. Yes, you see apples falling, but you didn't see gravity. I am of the believe that apples do fall because that's the God will, and I feel that if those statments from that Newton guy (who's Newton, after all?) can be thought in school my Holy Bible point of view (you can't compare God to that Newton, can you?) should be tougth too!
" without adding in a bunch about Macroevolution which we *can't* prove(Did *you* see personally see fish evolve into something else? )"
Certainly we can forget about teaching stars are hot gas spheres because, you know, you never touched one of them to know they are hot, do you? Or certainly, tell the Earth is about 4.5 billion years old, because nobody was there to tell.
Evolution by mutation is a coherent theory and it is the one that best fits with observations up to the point to detect genomic translocations responsible for diferenciation of some species. The only way not to see evolution as the prevalent explanation for life diversity is, oh well, some stupid variant of the freaking Spaghetti monster.
"The recording industries have their own exceptions built into the copyright code that prevents the lending of A/V media except as authorized. I'm sure if I'm wrong, someone here at/. will put in a kind work of correction with with the pertinent language "
The point is not if you are right or wrong but that *even if you were right* as soon as someone started to make good money out of it (the videoclub model) then the industry would either find a hole in the law or lobby new laws to take their share out of the profit (no matter that they *already* got their share out of the profit by selling the book).
"And that's why the original question strikes me as stinking of colonialistic snobbery."
The very Tahrir Square is stinking colonialistic snobbery. Nobody in his sane mind would put a, what? one hundred diameter square in the open in the mid of Cairo except because that's what "civilized" people (aka Napoleonic heritage) do, exactly because what the article referes to: 44ÂC under the Sun in summer.
"Spending other people's money on someone else (most government spending)."
Well, just exactly like corporations. You don't think a general manager or a CEO is expending *his* money, do you? He is expending *your* money via your retirement funds that go to the stock market.
"Because it's not their money, and they're not spending it upon themselves."
Yes, quite exactly like corporations. No wonder their success rate for big projects is more or less that of the government.
"I've done work on government projects and seen money thrown at projects that made absolutely no sense at all. Projects that just fizzled out or never got implemented."
"What is it about government IT projects that makes them go so disastrously wrong?"
Who said it's only the government?
Want to know one of the most (in)famous SAP fiasco back in the day? The one from the company that wanted to put itself as *the* reference consultancy for big SAP projects on its own implementation. The verily non-government HP.
"there are plenty of people who swear that the solution they know is the best one."
Well, my experience, that seems to be backed up by the very references you offer about companies migrating from RBDM to RBDM is that even more people tend to swear that the best solution must be any other *but* the one they know the best.
Slashdot Mirror
You didn't.
But of course yes!
Maybe you didn't notice but cost effectiveness is the difference between winning wars and losing them.
"Dimensional analysis isn't taught in high school!? Seriously!?"
Not needed. The ones that care always can transform measures into Libraries of Congress or Football Fields so everybody understands.
"The problem is it wasn't incurred against the electorates wishes, they didn't want to have their taxes raised and they didn't want to lose state benefits or services."
Are you aware that this takes all the "war effort" out of the equation?
Maybe, just maybe, the electorate could have their taxes not raised and the state benefits sustained if just USA government didn't push itself on a war-related expending galore.
By your account USA should have to be one of if not the safest country in the world to drive in.
How is it then that USA' s death rates because of car accidents are so ridiculously high?
It's seems a common trend: a clear indicative of the end of and empire is that it starts to depend on mercenaries for its protection.
So this Prof. Tim Murphy just has rediscovered Malthus... and it only took him 200 years. Wow!
"Hmm "data, images, other binaries" - nope, not seeing anything looks like source code to me."
Source is anything you need to start with in order to produce your deliverables.
For some people is just a bunch of text files. For other people is a bunch of text files plus a bunch of images. And, then, for another people is a bunch of text files plus a bunch of images plus a bunch of binary blobs. It all depends on your requirements*1.
"Don't know why you'd want to version binary data"
In order to be able to re-produce past releases, of course. I.e.: my product depends of my source code, some embedded images from my art department and some third party libraries I recieve as binary blobs.
Of course I could reinvent the wheel and produce my own in-house history control system but then, why would I *want* to do that unless -as it is the case, because of the inability of the SCM tool? Time and again people has been bitten by the "binaries within the SCM" problem but it has always been because the inability of the tool, not because having binaries as part of the sources didn't make sense.
"line by line diff doesn't work to well on them"
That's not the be-it-all of diffing. I may want to produce foo 1.2.3 to diff its *behaviour* against foo 4.5.6 to see when a bug was introduced. If my operational definition for "foo 1.2.3" includes something on the lines of "and the version of library bar that was used back then", so be it.
"and there's always backups"
Repeat with me: a backup, is a backup, is a backup and it is by no means a historical storage solution. A backup is (part of) the tool you use to recover your system to as near as possible a state after a failure. It has absolutly *nothing* to do with helping to your product delivery process and expecting it is as big a mistake as, say, thinking that RAID is a substitute for backups.
"I've personally never seen the point of versioning or backing up autogenerated data"
1) There can be other binaries apart from your own autogenerated data.
2) If there's the chance you won't be able to produce again in the future the same autogenerated data, then whatever you need to do it you should treat as source too (i.e., if foo 1.2.3 must be compiled with gcc 2.95.17, then you need to store gcc 2.95.17, tie it to the corresponding version of your sources and track the evolution of such correspondencies along time, be it within the SCM or not -of course, much the better if you can do it within a one single tool).
*1 For the most extreme case it might be source, binaries *and* blueprints *and* hardware, i.e. an ICBM guide and control system or a core banking solution. My requirements may include the ability to reproduce it from the ground up at any moment in the next 30 to 50 years. Of course I can't introduce some past model of a vacuum lamp in the SCM but again, it is not that I wouldn't want to do it (of course I would want to do something on the lines of `scm checkout --date 19700301 thewholesystem`) but that I can't (in this case both because of limitations of the tool *and* limitations of the physical world).
"Yeah exactly success is nothing but luck"
No. What he says is that luck is what makes the difference. A lot of people come with good ideas, hard word and even enough capital but only a few success. What's the difference between the ones and the others?
"The zero is not a significant digit, as a trailing zero with no subsequent non-zero values, and no decimal point after it."
So what you are saying is that the "nobody shall live longer than 120 years" is not an assertion but the measure of an empiric experiment? And that such experiment was unable to measure longevity with better precision than a decade? It this what you are saying? Because if that's not what you are saying I regretfully must say that you are miserably wrong.
"The problem is not that it's their job to accomplish this, it's the scientists saying "but the code is already written, you don't have much work to do" when this is, in fact, not true."
Of course is not. Nor it is (usually) among the scientist's abilities to to lead and valuate a software project effort. No news here.
"The further problem becomes when other people listen to the scientist and get unrealistic expectations of how long it will take for a product, which can be sold, to be ready."
While not a surprise this says nothing about the scientist but about the managerial abilities about the one believing nonsenses.
It is hardly the fault of the one obviously not knowing what's saying to say nonsenses but the fault of the one believing him when his job is to know better.
"I didn't forget it, I explicitly stated it."
No, you didn't and you still don't do it.
I'll say it again. There's no debt if there's no intention to repay it (or if, in fact, it is not repayed).
When you incur in a debt you have to repay the principal and the interests. If the code does all that needs to be done, then there's absolute nothing you will have to repay and it is not the case that the interest rate is low but that there is no technical debt *at all*.
On the other hand, if you -or others, happen to reuse the code in the future (but note the *if*) then there will be the case that certainly you will have to pay all you didn't pay before in the form of design or documentation *even* if it is you yourself the one modifying the original code (while certainly the interest rate for your own code will probably be less than that of a third party one, since then you'll have at least a bit of documentation: your own memories).
And here comes the point: the referenced article was talking about "a piece of research software [that] is suddenly expected to be ready for production", that is, a piece of code that never was meant to be used in production for third parties but all of a sudden *someone* which is not the original author, decides it can produce further benefits if productized.
Therefore there was no debt, what it is now is the need of further investment. For a different analogy, imagine you buy your home, just for you, your husband or wife and your two children and then, your boss decides that he will come to live with you and, by the way, to open a new office for ten people on the premises. Would you think you incurred in any kind of debt by buying a 300.000$ house instead of a 1.000.000$ building or is it the case that *for the new scenario* a new investment of 700.000$ is needed?
Expending more time and effort than needed up-front just in case is not covering (or not incurring) a debt, is just throwing resources away.
The "technical debt" concept is all well and good for productivity software (either in-house or meant to be sold away) and it is in fact a concept that quite a lot of directors if not managers should have continously present (and I purpousely am telling "directors if not managers" because I've sadly known quite a lot of managers perfectly aware of the concept but, as I said, there's not debt if there's no intention to repay it -I'll be far away when the shit hits the fan, they think) but still it is needed to understand when it's a valid concept and when it is not.
""Technical Debt". Your quick-n-dirty code that does what you need it to do carries a great deal of technical debt, but the nature of its limited use means the interest payments are small"
You seem to forget that the basic tenet on "technical debt" is "debt". There's not debt if there's no expectancy of having to repay it.
Which holds true for most of one-shoot code that scientists produce.
On the other hand, it might happen that some of the one-shoot code produced is seen as something of value by something else (may it be someone in management?). Then is up to said third party to pay what he sees as debt, not the one for whom the code already produced all that has to be done. In other words: if I am the scientist one coding my dirty hack for my own purpouses don't expect being me the one doing all that needs to be done on top of the special case code around an algorithm to evolution my dirty hack into your shinny product.
"the people who write it have never been educated in the importance of productising it."
Which is only important if your goal was productising it to start with.
Which for the most part, it is not the goal of for-academic-goals produced code.
You know, software can be written for different reasons.
"Yes, it works. It may even work quite well."
Then the scientist developed the code exactly to the point that brings him what he needs. That's good engineering practice, isn't it?
"It's another thing to be able to use it outside the original group that created it and another thing entirely to turn it into something that can be used by someone who wants to use the functionality for a completely different task."
Which if any, it is your jobs, not hims, to acomplish.
"I'm working on commercializing NASA software and this couldn't be more true."
I don't think is just NASA. Wasn't an IBM engineer the one that said: X time for a valid prototype; 10*X for an in-house product; 100*X for a commercial packaged application?
Given that what a scientist does for her calculations is in the "valid prototype" stage (why the hell would she be interested in anything else?) you can do the math about how much it will cost to put it on a shelf, so to say.
"if "120 years" didn't express what two significant digits does as a matter of basic math"
Well, it's obvious that 120 is *three* significant digits: the one, then the two and finally the zero. There's no magic in the ending zero and 120 is not "about twelve tens"; it is "one hundred and twenty".
On the other hand, there's nothing "scientific" about 120 being somewhere between 119.6 and 120.5 it is about the theory of measure.
Unless you don't have the confidence that the one telling "nobody older that 120 years" was able to count by the year and its ability only reached to count by the tens of years (or the century, or the millenia), 120 years is not even "somewhere between 119 and six months to 120 and six months" but exactly meaning "by their 120 birthday". And if it's an universal law -and that's it is in fact science, a single example is more than enough to shake the whole theory. Nobody over 120 years means no f* body, no exceptions, just like Einstein's theory would be under heavy problems if there were just *one* case of something going over C in vacuum ("well, that's 99.999999% accuracy" wouldn't make a case).
"Why shouldn't it be for debated?"
For the same reason they don't debate if cars run over four wheels or if fire is hot or not.
Because it's such an obvious fact to any minimally educated person that being for debate is a terryifically worrying symptompt of a very bad situation.
"Texas has yet to decide on the existeance gravity."
Well, every family has to have the option to decide how to teach their children and what their believes are, so they should have to have the option to teach alternate views about gravity.
After all is not as if you can prove gravity since you never saw it. Yes, you see apples falling, but you didn't see gravity. I am of the believe that apples do fall because that's the God will, and I feel that if those statments from that Newton guy (who's Newton, after all?) can be thought in school my Holy Bible point of view (you can't compare God to that Newton, can you?) should be tougth too!
" without adding in a bunch about Macroevolution which we *can't* prove(Did *you* see personally see fish evolve into something else? )"
Certainly we can forget about teaching stars are hot gas spheres because, you know, you never touched one of them to know they are hot, do you? Or certainly, tell the Earth is about 4.5 billion years old, because nobody was there to tell.
Evolution by mutation is a coherent theory and it is the one that best fits with observations up to the point to detect genomic translocations responsible for diferenciation of some species. The only way not to see evolution as the prevalent explanation for life diversity is, oh well, some stupid variant of the freaking Spaghetti monster.
"The recording industries have their own exceptions built into the copyright code that prevents the lending of A/V media except as authorized. I'm sure if I'm wrong, someone here at /. will put in a kind work of correction with with the pertinent language "
The point is not if you are right or wrong but that *even if you were right* as soon as someone started to make good money out of it (the videoclub model) then the industry would either find a hole in the law or lobby new laws to take their share out of the profit (no matter that they *already* got their share out of the profit by selling the book).
"And that's why the original question strikes me as stinking of colonialistic snobbery."
The very Tahrir Square is stinking colonialistic snobbery. Nobody in his sane mind would put a, what? one hundred diameter square in the open in the mid of Cairo except because that's what "civilized" people (aka Napoleonic heritage) do, exactly because what the article referes to: 44ÂC under the Sun in summer.
"Spending other people's money on someone else (most government spending)."
Well, just exactly like corporations. You don't think a general manager or a CEO is expending *his* money, do you? He is expending *your* money via your retirement funds that go to the stock market.
"Because it's not their money, and they're not spending it upon themselves."
Yes, quite exactly like corporations. No wonder their success rate for big projects is more or less that of the government.
"I've done work on government projects and seen money thrown at projects that made absolutely no sense at all. Projects that just fizzled out or never got implemented."
Yeah, exactly the same as corporations.
"What is it about government IT projects that makes them go so disastrously wrong?"
Who said it's only the government?
Want to know one of the most (in)famous SAP fiasco back in the day? The one from the company that wanted to put itself as *the* reference consultancy for big SAP projects on its own implementation. The verily non-government HP.
"there are plenty of people who swear that the solution they know is the best one."
Well, my experience, that seems to be backed up by the very references you offer about companies migrating from RBDM to RBDM is that even more people tend to swear that the best solution must be any other *but* the one they know the best.