Not now. Right now, I’m having a very dissatisfying email conversation with domainsbyproxy.com, DBP. They are protecting creativedevelopment.biz, CD. You will notice that I have not made them urls, by design. As far as I can tell, both of them are evil.

I called DBP today, to talk to someone—anyone about the emails from them that I do not understand. When you find abuse, you are supposed to report the abuse, and they follow up by email. I have provided my original writing link. I have provided the plagiarized link. I have provided evidence of copyright. They are asking for a good faith statement (which should not be necessary since I have claimed copyright), which I believe I have provided. I asked to talk to a manager. No manager was available. I asked to speak to someone who signed the paycheck of the person I spoke with. No one was available. The nice person told me they were all about security.

This is not security. This is about protecting criminals. This is about making it impossible to see who is doing business on the net. I would go as far to say that if you do business with DBP, you are the kind of person I do not want to do business with. You keep company with people who steal.

I put you people on notice. You want “security,” fine. I’m outing you whenever I cross paths with you. I will find bigger fish to tell. You common thief. Hide all you want. We will find you, out you, and crush you. Eventually.

I was at the Better Software conference last week, met a bunch of great people (including Jim Shore and Joel Spolsky).

Another important person is someone who’s not famous–and important nevertheless. A senior tester explained her situation and asked for some help. “Most of our testers can’t read code. And, we don’t know what the developers are putting into the code when they fix problems. Even if the testers could read the code, we don’t know what to look for. We don’t know what to test. The developers add and change features without telling us.”

I asked if the developers had to write check-in comments. She said that they did not. I suggested she work with the build people to write a script that forwarded every check-in comment to an email list of all developers and testers. If there was no comment, it would be an empty email with just the person’s name and the filename. If there was something in the email, she and the rest of the testers might have more information with which to test.

On this project, there is little transparency about who is doing what and the kind of progress they are making. Normally, I wouldn’t email check-in comments to an entire project, but if there is no other way to see what’s happening, it might work.

Transparency in a project is key to the project’s success. No, it’s possible that not everything has to be transparent. If you’re working on a project where you have different levels of clearance for product content (something that occurs on DOD projects), then it’s critical to keep some content opaque, not transparent. But most of us work on projects where transparency would help–sometimes dramatically.

I didn’t gratuitously name-drop at the beginning of this post–I had a reason :-) Both Jim and Joel make portions of their work transparent to the rest of us, so we can learn from them. We need to learn from our own projects too. If there’s a piece of your project that seems to be causing problems for another part, think about how you could make the output of the “troublesome” part more transparent to everyone. You may well discover the troublesome part is reacting to someone else’s work that’s not transparent.

If you’re a project manager or involved with project management in some way, think about what is not transparent to the rest of the people involved with the project. Could you create some transparency to make things clearer? It’s worth a little thought.