Of course you are forgetting the third thing - horribly unoptimized code that is also near enough totally incomprehensible. I was trying to fix an application, but ended up re-writing the thing from scratch because it was just too much of a mess 😱 . turned out much the better option though.
Ugh. Don't even get me started on that. **ROFL** I've had more than my share over the years. Hiring interns to write highly-customer-visible software is <i>never</i> a bright idea. Hiring them for a period of time not even long enough to complete the software development is even worse.
Not that it was entirely the intern's fault though, really. She did a pretty good job considering what she had to work with. (Since what she had to work with was a completely horrible example program written in Visual Basic 5 and in <i>French</i> for that matter. Comments and naming conventions do very little good when they're written in a language that you don't know. **ROFL**)
But anywho, from upgrading almost impossible-to-follow 16-bit x86 Assembly to 32-bits to correcting bad FORTRAN76 code (where all of the IF statements were in reverse logic because it was an IF ... GOTO instead of an IF ... THEN system and where all of the program-wide global variables were common blocks where the components of the blocks weren't even given the same variable names across the different components of the software) to upgrading pure ANSI C with no concept of object-oriented coding (and a plethora of global variables) to VC++ with actual classes to even completely re-writing an entire program in Python because it was originally bad code written in VC++ that had been made an even worse port to Java for cross-platform use (basically the code was so bad that in the end all that I could do was start over from scratch and use the software's functionality as the only guidance) to porting that previously mentioned VB5 project to VC++6 (and again rewriting most of it from scratch) I've just about seen the worst examples of software engineering that could ever be imagined.
Actually ... wait. The worst I've seen yet was when we outsourced the upgrade of a project to India to convert a VC++ program to Qt and C++. You'd be amazed how much more stable their code became when I did the very simple act of setting pointers to NULL after every delete command. Validating by checking if the pointer is non-NULL means nothing if you only set invalid pointers to be NULL a quarter of the time. If that gives you <i>any</i> idea of the quality of their work. (Or the fact that they claimed time and time again that it would compile under GCC for a Linux executable when it wasn't even ANSI C++ compliant. That took a little while to hunt down and fix the cause since they were ever so helpful.)
And to think, that's just getting me <i>started</i> on the subject. **ROFL**
But basically, yeah, the world would be considerably better if people actually wrote good <i>and</i> readable code. I try. I can't guarantee perfection, but at least I try, which sadly is far better than most from my experience.
And I've re-written several programs over from scratch by now and it really is almost always the best option. It might take more time initially (and sometimes depending on how bad the code is it might actually take less time), but maintanance is just <i>so</i> more efficient afterwords that it's always worth it to me. At least assuming that whomever is doing the re-write can write readable code and documents well.
<font color=purple><pre><A HREF="http://www.winamp.com" target="_new">Winamp<b><font color=blue>3</font color=blue></b></A> and freeform skins, the best thing since sliced llama loaf. (Now with more beef.)</pre><p></font color=purple>