| ??? 04/10/12 05:14 Read: times |
#187083 - Always prejudice from Richard Responding to: ???'s previous message |
Richard Erlacher said:
You professional coders don't like rigorous methodology. There is one person on this forum that just likes sweeping statements like that. Just as you make assumptions based on what people looks like, or what music they like. Problem is - you are just shooting out hot air. The word to use is "prejudice". You are a one-man operation. You don't work with any professional coders. You don't even work with projects that does involve real research. What do you think the R means in "R&D"? And you never ever respond to arguments that aren't backing your own, personal, view. You either pretend the arguments haven't been made, or you select some paragraph to specifically misunderstand and then try to run the debate in a completely different direction. That's why you don't like documentation. Who is "you" and can you show us how familiar you, Richard, are with this "you" you refer to? Documenting your design means specifying what you have to do before you do it, rather than commenting on what you did after the fact. And you still haven't figured out that in some situations, the only thing that can be documented beforehand is: "We want to implement a better security system for a car. The challenge we see is that the care can't be steered when wheels are locked, so the goal is to find a solution where either the wheels aren't locked or are locked for only a limited amount of time". Life isn't normally about a system that lights a lamp within 100ms of the detection of sensor A, unless sensor B forces a secondary behaviour. A system may use CAN for vehicle communication. But not until you have prototypes running, will you know if you need to implement specific filtering of the CAN messages because of the required volume of messages. Or how sensitive your design is to delays in feedback messages requiring you to increase the priority of the messages or maybe increase the bandwidth of the transfer channel. When discussing small/large project, you have now and then claimed to have worked with huge projects. Only you have then mentioned these huge projects to contain huge tables of lookup data. That isn't really big code. Someone implementing a service making use of a database don't incorporate the number of records in the database in the metric of size of the application. Moving the database into the source code doesn't change that fact. If you have worked with any project that requires iterative phases of coding/testing (which your previous statements implies you have not) to try to find a solution to a specific problem (problem as in invention, not problem as in bug), you would know that you could not have made any 100% documentation of the implementation before you started. That you claim code doesn't need to be changed if the documentation had existed beforehand just shows that you haven't been inside the loop of any inventive project. Maybe you have been a coder - but then someone else have been spending the time trying to invent. You have just come in when someone else have done all the "R" work. The majority of all references you have made to projects seems to be state machines, where all stimuli and actions are already known and there are known mathematical relations to use to compute the actions based on weight and value of the stimuli. But that only represents a sub-set of all development projects. The companies who wants to take market share aren't happy limiting themselves to that. All they can do then is to make a cheaper product following the same rules their competitors have implemented in their products. Companies wants to move away from too much price press - so they try to stretch the imagination. Find new solutions to problems that drastically changes the requirements. That allows the designers to hide their sloppy work, or lack of it, so they can't be sued for incompetence. The standard Richard prejudice. |
