One thing that businesses can learn from open source is that properly motivated employees can produce great things.
Here we have a group of technical professionals working for free to produce great software. Employers on the other hand, have a difficult time motivating people who they pay.
Motivation == productivity.
I'm surprised that hiding or rather preventing all evidence is not illegal in the first place.
There should be (and are) technological ways to keep informants anonymous (could be as simple as not logging IP addresses that connect to a site). However, without knowing who the informants are, how can you be sure of the validity of the information? It is a catch-22. Without knowing who the informant is, in most cases you cannot differentiate between a nut case, someone that wants to be anonymously famous and someone with very good insider information.
Yes, M$ must have been waiting for someone else to release a major OS so they can get ideas for Longhorn. That is the real cause of the Longhorn delay.
Yep... for a while I was holding out buying a new computer because I really wanted a Dell (Dell is pretty hassle free compared to most local mom and pop shops)... however, I didn't want to pay more for Intel CPUs when AMD is clearly leading the technology in the market. Eventually I couldn't wait any longer and bought another brand with AMD. I'm happy with the purchase.
Not too long a go, my mother and a computer illiterate friend asked me which computer they should get. I asked them to check whether Dell supported AMD and if not, buy elsewhere. They bought elsewhere and are telling their friends as well.
I really don't mind Dell. For the life of me, I can't understand why they don't support the technology leader in this industry.
I pitty those that have to investigate this sort of thing on a daily basis. Must be horrible.
I'm sure there is a lot that the technical community could to do help crack down on this crap. The only problem is that you'd get closer view of a horrible sub-culture of society. Probably wouldn't be the same afterwards.
The least we can do is not joke about the seriousness and show some respect to those that are doing the right thing by tracking down the sick fucks behind it.
Sure, I'll take the point that alpha/beta testing should be there near the end. Forgot that one.
However, you seem to have both overlooked step 4 and step 12 and yet mentioned indirectly in the same post. UCD (step 4) is critical for any tool and testing the entire resulting product (step 12) is the main test. This is where you'd bring in any real data that you have or attempt to mimic it.
Your last sentence really concerns me. I hope you don't rely mostly on your customers to test your product. The great system test group called "customers" is effective but they have better things to do then knock bugs out of your product. You need to have a good level of testing long before any customers see the product, even for alpha or beta.
Anyone who isn't successful at writing software the first two times around failed at the requirements and design phase.
You V3.0 people tend to dive right into writing the code before you have a clear understanding of what's needed and how to properly architect/design it. Then, say with pride "V3 is completely redesigned from the ground up". Translated: "We failed so badly the first time around, that we rewrote the same software again".
Rules of thumb:
1. Don't start anything until you clearly understand your problem statement
2. Don't start anything else until you clearly understand you end user. If the problem statement is "need to get to work quickly" and your end user is a student, don't design a $75k vehicle.
3. Create a clear and _short_ document that describes what you are going to build. Get it reviewed by many people (the more the merrier), especially your end users. Not only does this provide good feedback (e.g., "I can't use a $75k vehicle"), you might get some good, free ideas on how to build something better. At this point, consider ways to build the project smaller and still get something out the door. Yes, this is the MS philosophy of "good enough". Perfectionists have a difficult time with this stage but there is a lot to be said for good enough software. Your end users will get something in a shorter amount of time, you'll learn from your mistakes when they used the first version and you make some $$ in the mean time.
4. If you're building a tool, especially a UI, build a prototype, let your users test it out and expect to be wrong. You'll need a few iterations to get it right. As a developer, you rarely have the same "perfect UI" as normal people (e.g., you'd prefer more technical language, more complex UI, etc).
5. Think strategically, act tactically. Think about the future of what you're building. Can you create subcomponents that might be useful again some day? Build an architecture diagram if you're working on any significant project and have it reviewed. Think about "pluggable" components at this point. Again, think about "good enough" software.
6. Build crisp and well design interfaces (APIs). An interface that gets a lot of use from end users will be very difficult to change in the future. Build something that has at least some level of adaptability. For example, having a "options" argument as the first argument is not a bad idea since you can change the behavior at some point in the future without changing the API. This is the time to thing about "black box testing". Based on your architecture diagram and crisp interfaces, could you pull out a component and have it tested simply by driving its interfaces? Have the interfaces reviewed.
7. Once you have the components and interfaces designed, consider the design of each component. This is also a good time to go back to steps #1, #2 and #3 to make sure you're still building the right thing for your users and what they agreed to in step #3. Have the component designs reviewed.
8. Build the interfaces (read: write code). Pay special attention to serviceability of these interfaces. I.e., you might want to trace what is passed across these interfaces).
9. Build the components (read: write code). Again, pay special attention to serviceability. If something fails in these components, could you diagnose it remotely with your problem determination facilities?
10. Unit test. Test error paths and other "rare" code paths that would otherwise not be tested by driving the external interfaces. Test your serviceability features to make sure they work.
11. Test the externals by driving the components via their interfaces. If you have an automated test tool of some kind, get your tests hooked in. This might sound like a lot of work, but it is so good to know that if someone else's change "breaks the code" it is their fault and not your responsibility. If you don't have your code tested as part of the official methods, you'll be fixing problems that other people c
Slashdot Mirror
One thing that businesses can learn from open source is that properly motivated employees can produce great things. Here we have a group of technical professionals working for free to produce great software. Employers on the other hand, have a difficult time motivating people who they pay. Motivation == productivity.
I'm surprised that hiding or rather preventing all evidence is not illegal in the first place. There should be (and are) technological ways to keep informants anonymous (could be as simple as not logging IP addresses that connect to a site). However, without knowing who the informants are, how can you be sure of the validity of the information? It is a catch-22. Without knowing who the informant is, in most cases you cannot differentiate between a nut case, someone that wants to be anonymously famous and someone with very good insider information.
Ooops... I just bought it by accident using Amazon's 1-click.
Yes, M$ must have been waiting for someone else to release a major OS so they can get ideas for Longhorn. That is the real cause of the Longhorn delay.
Yep... for a while I was holding out buying a new computer because I really wanted a Dell (Dell is pretty hassle free compared to most local mom and pop shops)... however, I didn't want to pay more for Intel CPUs when AMD is clearly leading the technology in the market. Eventually I couldn't wait any longer and bought another brand with AMD. I'm happy with the purchase.
Not too long a go, my mother and a computer illiterate friend asked me which computer they should get. I asked them to check whether Dell supported AMD and if not, buy elsewhere. They bought elsewhere and are telling their friends as well.
I really don't mind Dell. For the life of me, I can't understand why they don't support the technology leader in this industry.
This is nothing. The druids used rocks to store the null character '\0' many hundreds of years ago.
Agreed.
I pitty those that have to investigate this sort of thing on a daily basis. Must be horrible.
I'm sure there is a lot that the technical community could to do help crack down on this crap. The only problem is that you'd get closer view of a horrible sub-culture of society. Probably wouldn't be the same afterwards.
The least we can do is not joke about the seriousness and show some respect to those that are doing the right thing by tracking down the sick fucks behind it.
Sure, I'll take the point that alpha/beta testing should be there near the end. Forgot that one.
However, you seem to have both overlooked step 4 and step 12 and yet mentioned indirectly in the same post. UCD (step 4) is critical for any tool and testing the entire resulting product (step 12) is the main test. This is where you'd bring in any real data that you have or attempt to mimic it.
Your last sentence really concerns me. I hope you don't rely mostly on your customers to test your product. The great system test group called "customers" is effective but they have better things to do then knock bugs out of your product. You need to have a good level of testing long before any customers see the product, even for alpha or beta.
Anyone who isn't successful at writing software the first two times around failed at the requirements and design phase.
You V3.0 people tend to dive right into writing the code before you have a clear understanding of what's needed and how to properly architect/design it. Then, say with pride "V3 is completely redesigned from the ground up". Translated: "We failed so badly the first time around, that we rewrote the same software again".
Rules of thumb:
1. Don't start anything until you clearly understand your problem statement
2. Don't start anything else until you clearly understand you end user. If the problem statement is "need to get to work quickly" and your end user is a student, don't design a $75k vehicle.
3. Create a clear and _short_ document that describes what you are going to build. Get it reviewed by many people (the more the merrier), especially your end users. Not only does this provide good feedback (e.g., "I can't use a $75k vehicle"), you might get some good, free ideas on how to build something better. At this point, consider ways to build the project smaller and still get something out the door. Yes, this is the MS philosophy of "good enough". Perfectionists have a difficult time with this stage but there is a lot to be said for good enough software. Your end users will get something in a shorter amount of time, you'll learn from your mistakes when they used the first version and you make some $$ in the mean time.
4. If you're building a tool, especially a UI, build a prototype, let your users test it out and expect to be wrong. You'll need a few iterations to get it right. As a developer, you rarely have the same "perfect UI" as normal people (e.g., you'd prefer more technical language, more complex UI, etc).
5. Think strategically, act tactically. Think about the future of what you're building. Can you create subcomponents that might be useful again some day? Build an architecture diagram if you're working on any significant project and have it reviewed. Think about "pluggable" components at this point. Again, think about "good enough" software.
6. Build crisp and well design interfaces (APIs). An interface that gets a lot of use from end users will be very difficult to change in the future. Build something that has at least some level of adaptability. For example, having a "options" argument as the first argument is not a bad idea since you can change the behavior at some point in the future without changing the API. This is the time to thing about "black box testing". Based on your architecture diagram and crisp interfaces, could you pull out a component and have it tested simply by driving its interfaces? Have the interfaces reviewed.
7. Once you have the components and interfaces designed, consider the design of each component. This is also a good time to go back to steps #1, #2 and #3 to make sure you're still building the right thing for your users and what they agreed to in step #3. Have the component designs reviewed.
8. Build the interfaces (read: write code). Pay special attention to serviceability of these interfaces. I.e., you might want to trace what is passed across these interfaces).
9. Build the components (read: write code). Again, pay special attention to serviceability. If something fails in these components, could you diagnose it remotely with your problem determination facilities?
10. Unit test. Test error paths and other "rare" code paths that would otherwise not be tested by driving the external interfaces. Test your serviceability features to make sure they work.
11. Test the externals by driving the components via their interfaces. If you have an automated test tool of some kind, get your tests hooked in. This might sound like a lot of work, but it is so good to know that if someone else's change "breaks the code" it is their fault and not your responsibility. If you don't have your code tested as part of the official methods, you'll be fixing problems that other people c