How You Play the Game
It's been said a million times: It's not whether you win or loose, it's how you play the game., and that's a great thing to tell kids to get them to realize that in life there are many times when we all can't win. It's a good lesson to know. It's a good lesson to learn. If I can extend it a bit, I'd say (for software development): It's not whether it runs or not, it's how the code was built..
I've been involved with many development efforts over the years and the without exception the phrase disposable code was universally inaccurate in every place it was used. The only code that I've ever called disposable code is that which I deleted right after I ran it just once. Everything else is going to get used a few times, and if it's used in a trusted capacity, then it's not disposable. It's got to be dependable.
Currently, I'm working with a group of software vendors whose product is fed through a Java interface. This Java interface doesn't have any package structure to it to help resolve the namespace issues that might arise. It was also delivered as a zip file of .java and .class files - no JAR file. Now there's no reason that these two things need to be in-place. Java certainly allows for package-less class creation, and the CLASSPATH can include directories of class files, but what vendor in their right mind would deliver their interface in that manner?
Oh, sure... I've written test classes and 'Hello World' apps without either, but those aren't the interface to my company's flagship product. They are simple little test apps that don't get any further than the development box. When things go into production - even for in-house development, there's always a package path, and they are most often delivered in JARs. The latter is bumped to an always when the code goes outside the company.
Yet I'm sitting here looking at the opposite. I'm stunned. The marketing types spun a good story, and while we (thankfully) haven't purchased the product (yet), it's these kinds of suprises that make me want to say "No matter how nice it seems, it's not built well under the covers. It'll break and we'll be left holding the bag."
I'm not sure how this is going to turn out. I'm hoping that when I ask for code samples, and any software engineering practices they have or use, that these things will stick out as incredible anomalies and the rest of their product will have been created with much greater care. But I'm not betting on it.