Are we as a technical society still at a point of ignorance in our understanding of privacy? Do we still think that it’s ok to offer up registration page that solicits personal information on the web with using ssl to secure the data?

Folks, come on. It’s 2009. Bandwidth is not that expensive that the cost difference between http and https traffic is going to make or break your business. It also just shows that you have no interest in showing responsibility for your customers information.

The offender is job.com. Shame on you.

Ok folks. This one is simple common sense. It’s kind of like not exposing yourself in public or not being vulgar around your parents. But it seems like I run into this situation at every company I’ve been at. Simply put: some jackass thinks it’s cool to name some super secret cool project with an ironic name (with possible sexual overtones) that may not be appropriate if a customer ever finds out.

Cool? Yes. Innocent? No. A bad idea? Yes. Why? Because it will likely make it’s way out into the real world and your customers will see it. It would be a rare case of it not actively hurting the company. Let give you an example and let me preface it by saying that names have been changed for my benefit alone. It’ll be obvious to the folks who were there.

I was working with group that had previously been a startup but were now apart of a large company after an aquistion. Most of the folks from the startup years still maintained their sense of humor and tried to make working for a big company interesting. So they were producing a security product and one of their current projects at the time was to implement a new authentication protocol. All concerns about implementing new methods of authentication aside, there was a lot of effort put into getting it right. This new authentication protocol had a long name but the acronym boiled down to d.r.u.g (again, names changed…).

When it came time to implement the daemon to manage the protocol interaction, they of course continued the theme and called the daemon d.r.u.g. dealer. (You can probably see where this is going). In testing, logs messages indicated that the d.r.u.g. dealer was providing to the addict (the client in the auth transaction). All through development and testing, the name inspired jokes and kept us laughing during one of the roughest release cycles we had seen.

Well, we shipped and moved on to the next release immediately. However, someone along the way neglected to change the name for our d.r.u.g. dealer. Not too long after, a customer called up to trouble shoot a problem with this new authentication protocol. When support asked for information from the logs, it was discovered that the d.r.u.g. dealer was still providing for the addict. The customer was more than a little shocked and support was extremely embarrassed by the situation. Needless to say management was unhappy and the engineering org got our asses chewed out.

‘Nough said?

At an established company after hours projects should be reserved for cool new developments, neat hacks and other such refinements. Not for updating, upgrading and migrating existing software tools infrastructure during an high intensity release schedule. That’s the gist of the conversation I just had with one of the over achieving yet completely demotivated founders of the company I currently call my day job.

About the day job: It’s for a company that’s been around for a couple of years. It’s gone beyond the startup phase and really pushing toward the adolescence phase where a company is growing from 20 people to 100. Even the slightest impact on the release schedule at this point is detrimental.

Anyways, I am all about adding, updating and modifying the tools that we use on a day to day basis in order to achieve our goal of developing good software. But there are some really basic requirements that have to be met in order for these changes to be effective:

• Changes need to planned. If the work needs to be done during a tight release schedule, add it as an actual task so that the impact can be understood.
• We can’t negatively impact the existing workflow of the existing toolset while implementing the new one.
• The addition, change or modification needs to be throughly tested before introducing it into the tool chain.
• The change needs to make the workflow of the tool chain easier. Otherwise users will balk at the change.
• And above all else, it’s not a side project when you’re changing development tools. The impact is important enough to take the work seriously.

Did I miss anything?