What's it all about, Alfie?

I've done it again. I can't for the life of me tell you why I do it other than I'm a Dad, and when it comes to what's right and what's easy I try to teach my kids that it's the right thing that's worth doing. Always.

So I'm trying to suggest that things at work change. Not a lot. Just make us look at what we're doing. Stop and look at things. That's all. But I've been accused of being afraid that my job would be eliminated by the success of this one project. Even if this project was perfect... even if it did everything it was capable of, and then some, I wouldn't be worried. Why? Because I've talked to the management and they have me working on more things every day. I'm in no risk. Yet everything I say is going to be discounted by the people working on the project because of what they feel are my actual motivations.

So in a way, it's a sad statement of paranoia. They feel certain that I can't be trying to help them so everything I say is tossed on the floor. They don't stand a chance of getting better without some help, but they don't want to listen to me.

Still, because I'm a Dad, and I'd tell my kids to do the right thing I'm going to keep trying. Wasting my time, probably.

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.