good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Thank you for your reply. where any failure is simply not acceptable Yes it is. However, many such situations exist today where a single bug will completely destroy a company's reputation and open them up to severe liability. A single bug in certain medical systems could easily cause many deaths. A bug in flight control software can cause (and has caused) a hundred million+ dollar mission to end in failure. But how can you expect substance, "working code", stuff that can be "directly applied", etc, in the context of talking about programming in general? You'll have to obviously narrow the field a bit to get to the level I'm requesting, but narrowing out brainfuck doesn't exactly eliminate a good portion of your audience. Pseudo-code, class diagrams, etc can be equally applied to Perl, Java, Python, Ruby, C++, and almost any language in popular use today. The causes of software failure constitute an open set. They include not only things that are arguably wrong in the code design, but also varieties of data or operating conditions that no programmer could anticipate, no matter how careful or thorough the design and testing. Actually, I disagree. Provided that the supporting systems interfaces are accurately and fully specificed and that they do not fail, the responsibility rests entirely on your code. If everyone follows that strategy then you will have a flawless system (this is obviously a lot harder at the hardware level). The task is not to complete the entire product perfectly, but to complete your software's functionality perfectly. In order to learn the best way to write code, and in order to improve your skill as a programmer, you have to write code, fix code, review and critique code, and be involved enough in each particular application domain to know what the code should be doing Yes, but after that what happens? To continue simply learning a simple fix here and there will not result in the reliability required for such systems. In reply to Re: Re: Software Design Resources
by Anonymous Monk
|
|