7fff – think max value

Managing passwords with PasswordMaker: Know your settings!

I have long been a fan of PasswordMaker (http://passwordmaker.sourceforge.net/).

What it does is generate a hash based on a domain (e.g., google.com) and a secret that you know (e.g., “topsecretpassword”). Then that hash becomes your password. You typically use the same secret with all sites, though you could vary this. Then PasswordMaker generates a password of a standard length and character set, based on the hash algorithm you use. So far, so good. It has a great Firefox plugin, and version for the command line, as a Yahoo widget, etc. The Firefox version provides a hot key ALT-` which opens PasswordMaker, allows you to enter your master password, and then the password field you’re typing in gets pre-populated. There is also a JavaScript version, which is what this post is about.

So: one thing you want to make careful note of are the standard settings: The number of characters you desire, the algorithm, and the character set. I, for instance, have found that numerous sites do not allow characters outside the AZaz09 range (why, I know not). So I use a relatively constrained character set (but a longer password length). Some sites even restrict the number of characters, which is a shame, because if password generation is automatic, you might as well use 128 characters, 196 characters, whatever turns you on.

Why do you want to note all this stuff: I traveled over the holiday, and left my laptop at home; and without MY Firefox with my PasswordMaker with my settings, I was hobbled. I couldn’t remember my character set, etc. So you should keep those passwords.

Indeed, I would strongly recommend downloading the JavaScript version, and editing the code so that when you bring the page up from your hard drive (or from SVN . . .) you can quickly type in your master password and get the domain-specific hash without the Firefox plugin. Or you might put this page on a web site you control so that if you’re away from your tricked-out browser, you can still generate a hash when you need one.

Management and the bugs database

Several years ago I worked in a company where non-engineering staff could see everything in the bugs database. A colleague, let us call her M., who was the SVP of Marketing, approached me: “John, why haven’t you fixed Bug 2050?” Me: “I don’t think it’s been assigned to me.” M.: “Well, it’s really important, and I don’t understand why the priority has been marked as low, or why the estimate says 2 hours. It’s just a word change.” Me: “ummm, can I get back to you?” M.: “And why does the comment say, ‘this is just a cosmetic detail for M., but it’s buried in the dynamic image routine, so we should bundle it with other changes in that area.’ John, it’s a lot more than a cosmetic change.” I know M.’s motivation: She was trying to do her job. But because of her insight into the bugs database, we were probably slowing her down (because she was spending time browsing it), and she wasn’t playing the project management game. Which leads me to . . .

(photo from http://www.digitalapoptosis.com/archives/costa_rica/000583.html)

Q1: Should management have access to the bugs database?
A1: It depends.

The answer to all project management questions is “it depends,” know ye not that? So I’m being a bit facetious in my answer. Here’s another version that provides as little information but is perhaps better phrased and the answer that I will draw out in what follows:

A1: The more the culture of a manager is like the culture of the developers, the more access that manager should have to the bugs database.

Now in this answer I’ve used the singular with the manager and the plural with the developers. In my experience, the developers do have something of a shared culture, while the managers are at various degrees of difference to the developers. So each manager needs to be considered separately. By “managers,” I am thinking about sales and marketing, as well as VPs and above, including the CEO. The project and product managers are, from this perspective, developers: They need full access to the bugs database so that they can translate to the non-developers.

Incidentally, by “bug,” I mean any developer “to do,” be it a task associated with a new feature, or a system management job, or an actual bug fix. The bugs database I’m talking about it is that which manages developer work. There may be other important things in the bugs database: For instance, the product manager may store feature descriptions or requirements in the database, which ultimately are aggregations of todos (i.e., bugs, i.e., things developers must do). But these are not bugs; they are at the manifold between developers and management. One thing I won’t discuss here is bug management by CRC cards and the like, which are commonly on view in the developer offices; when CRC cards are on display to non-developers, they will have a different tone compared to cards that live only within developer world.

And why would this ever come up? At some point in your project or company’s development, someone will say: Wouldn’t it be convenient to let marketing know where the project is by giving them access to the bugs database? Or, it might come to pass that someone suggests that marketing should be able to add stuff to the bugs database on their own, thus eliminating any filtering provided by those who are in charge of development. I have seen this in some form in about half of all of the projects I’ve been involved with.

In any case, why is this an important question? The reason is that on your development team, the developers need to be brutally honest with themselves and with each other in the bugs database. They need to be honest about their emotions, and about their facts. Emotions first: Good software for managing bugs includes comments, and on occasion developers need to say sarcastic things about the person who submitted the bug, the customer, or another developer. Why? Because frequently items get into the bugs database that are not bugs (according to developer culture), and this semantic slippage drives a conversation in the bugs database. That conversation isn’t about the bug per se, but a metacommentary on the very nature of bugs. If you don’t know what I am talking about, then you are a manager and shouldn’t have a login to the bugs database. You will mistake what the developers are saying as “mean” comments, or comments that are not positive and supportive of the company. Trust me, they are not mean: They are emerging from the developer collective unconscious, which transcends (or supports in the manner of a sewer system) all particular companies and institutions.

The metacommentary is special. In linguistics, there is something called the “phatic” dimension of language, which means statements that exist to perform a social task: You could argue that “um” is a phatic utterance, because it is saying: “I’m still here, I’m still talking, don’t interrupt me . . .” The bugs meta-commentary is like that. It is the developers making small-talk that effectively says: “I am a developer.” To be sure, there might actually be content in the meta-commentary, but its phatic dimension is crucial.

Another important element in a good bugs database is an estimate for each bug, and a hierachy between particular bugs and various higher-level components. On the estimates side, you can’t plan if people aren’t honest. It can happen that if someone in marketing or sales knew the true estimate for a bug, that person would panic. What needs to happen in this case is that the customer representative / product owner, who is an honorary member of developer culture, must know the estimate so that, if the estimate exceeds the time allowed, a different kind of fix can be imagined or the scope of the bug and/or its fix can be altered. Scrum has this correct through its division of the participants in the product development process: Obviously stakeholders need to know exactly where the project is: But they need to know it in a language they understand, with options. (Some of the developer attitude comes through in Scrum slang: pig roles, chicken roles, etc.) Those options come from studying the real estimates, and then coming up with alternatives. But the baseline for this discussion has to be honesty, the kind that can be very disturbing to stakeholders — unless, of course, they participate in developer culture and already know that the estimate is subject to alteration on the basis of changing the bug itself or the scope of the fix.

So . . . having said this, my conclusion is that managers who are far from developer culture should not have access to the bugs database. They should not be able to add items to the bugs database; they should not be able to add commentary; they should certainly not be able to see, or worse, change estimates. All reports from and modifications to the bugs database should be carried out through an intermediary, such as the project or product manager, who can identify suggestions as duplicates, and/or respond to stakeholder needs in terms of speeding up the schedule (read: de-scoping what is to be done).

You can also run this in reverse: Is your CEO still a techie, deserving of exposure to the developer mishnah? Judge him or her by use of the bugs database. If the CEO has access to the bugs database, and takes offense at the meta-commentary, he is no longer a part of developer culture, and should be banned. If the CEO tweaks an estimate without consulting the project and/or product managers, again, that CEO has migrated away from developer culture, and should be banned. It will be better for the CEO, too: Clearly he or she needs to be updated about project velocity in a language that fits CEO prerogatives better . . . raw exposure to developer world is going to be counter-productive.

Some readers will feel that user-contributed tickets should be managed by the same software; i.e., that there is “input” to the bugs database that should be untranslated, or that should be managed by those in charge of customer communications, typically people from marketing. If the bugs software maintains a categorical wall between user-submitted tickets and actual bugs, then I think that’s ok; otherwise, such submissions from the real world need to be triaged by project and product managers just like everything else.

Disclaimer: No similarities to living or dead developers, bug databases, project managers, product managers, scrum masters, CEOs, VPs, sales and marketing staff, are intended or implied.

The March of Progress

From Cay Horstmann (http://horstmann.com/)

1980: C

printf("%10.2f", x);

1988: C++

++cout << setw(10) << setprecision(2) << showpoint << x;

1996: Java

java.text.NumberFormat formatter = java.text.NumberFormat.getNumberInstance();
formatter.setMinimumFractionDigits(2);
formatter.setMaximumFractionDigits(2);
String s = formatter.format(x);
for (int i = s.length(); i < 10; i++) System.out.print(' ');
System.out.print(s);

2004: Java

  System.out.printf("%10.2f", x);

And how did I vote?

Don’t read this if you’re going to vote for an AWS start-up . . . scroll down . . .

.
.
.
.
.
.
.
.
.
.
.
.

Brainscape: Out (obviously University-backed, so not a real startup IMHO)

Commerce360, JustinTV, Ooyala: These are just ad vehicles, and, hence, promoting the worst aspects of the web.

MileMeter: Doesn’t sound like they make enough use of AWS. Great idea, though, and obviously the only one that returns any value to society.

WeoGeo: They have other products, so I can’t consider this a real startup (nice guys, though).

So that leaves, by process of elimination:

UserTesting.com, who have the lamest video and the fewest votes. Still, I can tell you that providing testers on demand is something that someone is going to provide sooner or later; and it is potentially a services hawg, so appropriate for AWS.

Software that just isn’t right

I’ve been thinking a lot about software I use that, in the end, just isn’t right. Here are my two top candidates for destruction right now:

1. Adobe Reader on Windows. Yes, the software that displays PDFs. Before I begin, note that Reader (version 8.0) is a 22MB download. Wow. As I watch the file names go by during installation, I see the likes of SOAP.API, and I’m thinking: Sheesh, the stupid thing uses web services? Please. Can we just do one small thing right? Like display a PDF? In any case, here are my top gripes:

A. I don’t know WHAT is up with printing out of Acrobat, but if your printer is on a network, it can really get wacky with ginormous pauses during print setup that make no sense. I don’t really care if there’s an explanation: It’s just wrong. To be sure, my printing is hooked up via a wireless printserver, but, you know, I just don’t care. Maybe it’s because it’s a biggish PDF (8 MB). But again, I don’t care. It doesn’t work. Every other program I use prints fine. But not Acrobat. No doubt it is doing some bi-directional communication with the printer, and there’s a lot of latency, but, again, it’s just broken, bad design, I don’t know what. Maybe I can blame the printserver, but I don’t think so.

B. Viewing PDF in the browser. Every power user will tell you that on Windows, you never read a PDF in the browser. It is just too likely to hose your browser. Everyone downloads. I have had discussions with people who think it is appropriate to direct the user to just (left) click a link for a PDF, but then you will get the complaints for some poor end-user who follows directions that something is screwed up and the PDF doesn’t appear. Well, tell those users to right-click and download the PDF to the desktop, and then open it up with Acrobat.

C. An old one: PDF is just too proprietary. I’m sick of it.

I would guess that Apple’s version has been tweaked to play nice with everything. Maybe when I get my new Mac in January my excuse will be: I want PDF display and printing that doesn’t stink.

2. Outlook. The skin is nice, but the guts are bad. The latest thing that has been driving me bananas is this. I leave a computer on overnight, and Windows wants to do its automatic updates. I let it do its thing, because I want the security updates right away. So what does Windows want to do afterwards? Reboot. And if Outlook is running, what does Windows do? Terminates it. And when Outlook starts up, what does it want to do? Verify the stupid PST file. UGH! Stop the madness! Why does Outlook keep it open in such a way that termination might result in a file that needs verification!? It’s awful software design, and on these grounds alone should be banned.

I could go on.

I don’t feel better after this rant.