I think people are missing the point of a snapshot appearing as the icon for the file (which isn't surprising because TFA didn't mention the punch line). The real value of this "icon preview" feature is that you can zoom it in real time using the mouse wheel and see what's in the file. That's the real feature. You can see what's in the file easily, in the Find... um, I mean.. Explorer, without "opening" the file. Thomashawk's review mentions this.
It sounds like MS took a page from Jef Raskins bag of tricks.
I write software for a living, so that's where these comments are coming from.
It seems to me that the IEEE is doing a great job of making itself totally irrelevant to the software community. The main reason for this is that people, who might otherwise be interested in what they have to say, are turned off because IEEE charges a hefty fee to access any of their content (standards or articles).
A quick example. You are about to introduce unit testing to your team. Do you know that IEEE has a standard for that? Probably not. Even if you knew it, would you pay $65 for a Xeroxed copy of it? Would it be any better if you were a IEEE member and could get it for $55? Probalby not, because you can find similar information for free on the web. It's not exactly the same because it's scattered all over the place and hasn't been peer reviewed, but it's good enough.
I think that opening up the stacks to everyone, free of charge or for a nominal fee, would be a good move for the IEEE that would make them more respected and relevant. They have accumulated a large amount of information about how software is done, but nobody pays any attention because the cost is too high. In my 10 years in the software business, I've only had ONE co-worker who was a IEEE member and I've never seen a IEEE software standard.
To my mind and experience, the greatest benefit of Agile methodologies is that all of them put a premium on communication. Many of the practices (pair programming, on-site customer, etc.) are aimed sqaurely at fostering communication between team members.
Test-driven development is a good tool and because it's one that's easy for programmers to understand, it's usually the first Agile practice to get adopted. However, I don't think that it's the only (or even the most) valuable one. I can do good work without formal unit tests, but I can't do good work without an on-site customer who can answer my questions as I write code.
A word about specs. Specs are not a substitute for the customer. Read that last sentance again. Print it out, frame it and hang it on the wall. You shouldn't be writing to satisfy the spec, you should be writing to satisfy the customer. My experience with detailed specs is that they only work for well-known problems with limited scope.
Slashdot Mirror
Too bad that the IEEE standards cost $$$ to view :(
It sounds like MS took a page from Jef Raskins bag of tricks.
It seems to me that the IEEE is doing a great job of making itself totally irrelevant to the software community. The main reason for this is that people, who might otherwise be interested in what they have to say, are turned off because IEEE charges a hefty fee to access any of their content (standards or articles).
A quick example. You are about to introduce unit testing to your team. Do you know that IEEE has a standard for that? Probably not. Even if you knew it, would you pay $65 for a Xeroxed copy of it? Would it be any better if you were a IEEE member and could get it for $55? Probalby not, because you can find similar information for free on the web. It's not exactly the same because it's scattered all over the place and hasn't been peer reviewed, but it's good enough.
I think that opening up the stacks to everyone, free of charge or for a nominal fee, would be a good move for the IEEE that would make them more respected and relevant. They have accumulated a large amount of information about how software is done, but nobody pays any attention because the cost is too high. In my 10 years in the software business, I've only had ONE co-worker who was a IEEE member and I've never seen a IEEE software standard.
To my mind and experience, the greatest benefit of Agile methodologies is that all of them put a premium on communication. Many of the practices (pair programming, on-site customer, etc.) are aimed sqaurely at fostering communication between team members.
Test-driven development is a good tool and because it's one that's easy for programmers to understand, it's usually the first Agile practice to get adopted. However, I don't think that it's the only (or even the most) valuable one. I can do good work without formal unit tests, but I can't do good work without an on-site customer who can answer my questions as I write code.
A word about specs. Specs are not a substitute for the customer. Read that last sentance again. Print it out, frame it and hang it on the wall. You shouldn't be writing to satisfy the spec, you should be writing to satisfy the customer. My experience with detailed specs is that they only work for well-known problems with limited scope.