Crappy software is a rampant with enough blame to cover all aspects of its production from the top to the bottom of the corporate management and engineering structure.
Good software is hard to write.
Good software is hard to design.
Good software is time consuming to produce.
Good software engineers are hard to find.
Good software engineers are experienced.
Good software engineers are expensive.
Short schedules and low cost are in direct conflict with good software.
What you say is true... however...
The assumption is that through-put/performance is the only advantage to a multi-threaded approach. A well architected multi-threaded system provides another means of partitioning a problem to improve maintainability and scalability.
The good programmer you are looking for likely mainly has to be a good designer. What most bad programmers mis IMHO is the ability to analyse a given problem, chop is into pieces and work out a technical sollution. Every good coder does that, knowingly or not. When you separate this part from the actual coding you can simply document the sollution and have a 'decent' programmer to write the actual code.
While I agree coceptually with this statement, it is often true that once I have gotten to the point of adequately (not simply) expressing a design, I could have more easily coded the solution.
Unaffected?
Tell that to my disk drive.
Tell that to my bandwidth.
I sure am glad that I'm not using dial up anymore.
Most of the stinkin' things contains a 145275 byte
fsckin' executable!
Slashdot Mirror
Crappy software is a rampant with enough blame to cover all aspects of its production from the top to the bottom of the corporate management and engineering structure. Good software is hard to write. Good software is hard to design. Good software is time consuming to produce. Good software engineers are hard to find. Good software engineers are experienced. Good software engineers are expensive. Short schedules and low cost are in direct conflict with good software.
What you say is true ... however ...
The assumption is that through-put/performance is the only advantage to a multi-threaded approach. A well architected multi-threaded system provides another means of partitioning a problem to improve maintainability and scalability.
Given the list of applications, the optical part appears to be a long way from being a general purpose processor, or even a DSP.
Unaffected? Tell that to my disk drive. Tell that to my bandwidth. I sure am glad that I'm not using dial up anymore. Most of the stinkin' things contains a 145275 byte fsckin' executable!
I guess that means that spam is doomed ;-)