Can we have some discussion without "so my guess", "arguably", and so on? Insinuations and personal attacks most definitely detract from any other arguments you present.
Bills and coins only represent 3 percent of the economy. Engineers are only a small percentage of our population, does this mean we are moving towards an engineer-less economy?
Please don't confuse a balanced equation with an absolute endpoint. The balance between two models will shift back and forth, but both will always be with us.
The only way to describe most of the comments here is "industrial strength cluelessness." As in, the coments' authors don't have a clue about product development. They would have made the Judy Garland/Mickey Rooney movie in the 40s, "Hey, I have a keyboard and Jimmy's dad has a monitor, let's write an app!"
Yes, the government holds contractors on tight leashes. Contract assignment is being done more and more heavily based upon past performance -- your last few contracts were duds, you're less likely to get the next one.
And yes, there is a lot of time spent on product specs. Full life cycle SDLC. Agile development where is is appropriate. Understanding the target before you write a line of code.
Exactly the opposite of what most of the code monkeys making comments above are used to.
So yes, there will be specs written before the product is architected. And it will be written for maintainability. And it will be tested before release. And yes, during the initial development period, this costs money. Because, and remember this, there isn't revenue built into the back end (it isn't "sold" or "advertising supported") to pay for fixes, rewrites, and handling customer complaints.
Disclaimer: I'm a government contractor. I don't code. I'm part of the analysis, review, and verification process. And I've seen a lot of extremely complex systems go out on time and work well when released.
Your PhD won't be "in" biology. If relevant to your employer, your PhD is "in Computational Modeling and Machine Learning for Biological Systems". It was granted by a biology department, but that's not relevant.
And yeah, as has been pointed out, in all probablility, in five years you'll be doing something else. Hopefully equally interesting.
Yes, Linux can compress files and you can browse within the compressed archive. Yes, Linux could do that 20 years ago. Hell, so could my CP/M system, 30+ years ago.
The central question is transparency of access across all applications. A brilliance of Unix was the transparency of access to byte streams across sources through the use of the filesystem integrated with driver references. An application sees a byte stream of data, and doesn't care if it is bytes stored on a disk or bytes being read from a TTY device. The concept of "filesystem" includes layers that are (reasonably) consistent across sources to provide a common interface to the data source.
Embedding compression adds additional layer of transparent functionality. The application sees a name, if it is a directory it can proceed to open the directory and query for objectnames within it. The app need concern itself with only files and data; the filesystem manager maintains the source processing models (including, by the way, what kind of filesystem (EXTx, etc.) is used to manage the data store).
I don't agree with MOST software patents. However, some are insightful, advancing, and provide a non-unique approach to a problem. GIF encoding (like it or not), RSA, ZIP file encoding. No one can deny that other technologies exist for compressing or securing data. And if other solutions exist, the problem domain is known, so no one can say that the patent prevents others from working within the domain. All are non-obvious solutions. Read the algorthm some time, yes, it is non-obvious. Non-obvious does NOT mean difficult, it just means that the normal practitioner would probably choose a simple(r), already-existing solution rather digging into the creation process.
One-click shopping, on the other hand... And linked pages...
Slashdot Mirror
Can we have some discussion without "so my guess", "arguably", and so on? Insinuations and personal attacks most definitely detract from any other arguments you present.
Sorry to tell you this, but half of all children are below the MEDIAN.
C NO DONT USE COLUMNS 73-80 00000010
C THEY ARE RESERVED FOR SEQUENCE NUMBERS 00000020
Bills and coins only represent 3 percent of the economy. Engineers are only a small percentage of our population, does this mean we are moving towards an engineer-less economy?
Please don't confuse a balanced equation with an absolute endpoint. The balance between two models will shift back and forth, but both will always be with us.
The only way to describe most of the comments here is "industrial strength cluelessness." As in, the coments' authors don't have a clue about product development. They would have made the Judy Garland/Mickey Rooney movie in the 40s, "Hey, I have a keyboard and Jimmy's dad has a monitor, let's write an app!"
Yes, the government holds contractors on tight leashes. Contract assignment is being done more and more heavily based upon past performance -- your last few contracts were duds, you're less likely to get the next one.
And yes, there is a lot of time spent on product specs. Full life cycle SDLC. Agile development where is is appropriate. Understanding the target before you write a line of code.
Exactly the opposite of what most of the code monkeys making comments above are used to.
So yes, there will be specs written before the product is architected. And it will be written for maintainability. And it will be tested before release. And yes, during the initial development period, this costs money. Because, and remember this, there isn't revenue built into the back end (it isn't "sold" or "advertising supported") to pay for fixes, rewrites, and handling customer complaints.
Disclaimer: I'm a government contractor. I don't code. I'm part of the analysis, review, and verification process. And I've seen a lot of extremely complex systems go out on time and work well when released.
Your PhD won't be "in" biology. If relevant to your employer, your PhD is "in Computational Modeling and Machine Learning for Biological Systems". It was granted by a biology department, but that's not relevant. And yeah, as has been pointed out, in all probablility, in five years you'll be doing something else. Hopefully equally interesting.
I fail to understand this response.
Yes, Linux can compress files and you can browse within the compressed archive. Yes, Linux could do that 20 years ago. Hell, so could my CP/M system, 30+ years ago.
The central question is transparency of access across all applications. A brilliance of Unix was the transparency of access to byte streams across sources through the use of the filesystem integrated with driver references. An application sees a byte stream of data, and doesn't care if it is bytes stored on a disk or bytes being read from a TTY device. The concept of "filesystem" includes layers that are (reasonably) consistent across sources to provide a common interface to the data source.
Embedding compression adds additional layer of transparent functionality. The application sees a name, if it is a directory it can proceed to open the directory and query for objectnames within it. The app need concern itself with only files and data; the filesystem manager maintains the source processing models (including, by the way, what kind of filesystem (EXTx, etc.) is used to manage the data store).
I don't agree with MOST software patents. However, some are insightful, advancing, and provide a non-unique approach to a problem. GIF encoding (like it or not), RSA, ZIP file encoding. No one can deny that other technologies exist for compressing or securing data. And if other solutions exist, the problem domain is known, so no one can say that the patent prevents others from working within the domain. All are non-obvious solutions. Read the algorthm some time, yes, it is non-obvious. Non-obvious does NOT mean difficult, it just means that the normal practitioner would probably choose a simple(r), already-existing solution rather digging into the creation process.
One-click shopping, on the other hand... And linked pages...