...workers are people, and people are messy. They aren't software you can debug and fix. If you are a manager, get used to it. Until someone develops a useful workerbot, you are stuck with actual humans as workers.
So true. Like it or not, we've all got feelings, families, and lives that co-mingle with our everyday work, and we have to not only be aware of that fact, but we need to take it into consideration.
If you want to see how I and some of the other programmers are attacking it, here's the thread that I've been trying to keep up with. If you want to try out the challenge for yourself, I'd suggest writing your own implementation of the algorithm without looking at the code that people have been posting, and then tweaking it a little, and then comparing it to the other functions on the forum. You may be surprised at the speed difference.
Down around these parts, we get a lot of Georgia thumpers -- more properly referred to as Eastern lubber grasshoppers, or even more properly as Romalea guttata. For those of you who think you have large insects where you live, here are a couple of pictures for you: one on my window (that's a ruler next to it), and one on my house. The adult grasshoppers get to be over 3 inches/8 cm long, which makes them appear to be like prehistoric creatures living in the shrubbery.
No point to this story, really. I guess I just wanted to share my pictures.
I happened across a news article regarding an infestation of giant gerbils in China. According to the opening line of the article, "China is deploying eagles to control giant gerbils that have damaged an area of grassland larger than Switzerland."
All right, that sounds pretty serious, even though the thought of a herd (swarm? army?) of giant gerbils brings thoughts of bad science fiction "B" movies from the 50's. But then there's this quote from Xiong Ling, "an official with the region's headquarters for controlling locusts and rodents" (there's a whole department to deal with such things):
"It has been the most severe rodent disaster since 1993"
Since 1993? You mean there was an even larger rodent disaster in 1993? Worse than destroying grassland the size of Switzerland? My gosh. I just can't imagine...
BTW, if you'd like to find out more about the giant gerbil (Rhombomys opimus), the article used the National Gerbil Society's website as a reference.
I also decided, just for the heck of it, to put together a list of books that I like. It's just fiction and non-fiction so far...I'll probably add some computer books when I get around to it. These are books that I've really enjoyed reading, and that I can honestly recommend to other people. If you're looking for something else to read this summer, maybe you'll like them too.
Then it occurred to me: nothing else I write is especially meaningful or significant, so why should today be any different? So instead of writing something new, I decided to make a list of links to entries I've written over the past year that you might enjoy reading again -- or for the first time, for the newer readers. Sorry if that seems arrogant ("Hey, look at all this interesting stuff that I'VE written"), but it's really meant to be a good quick way to recap the year of blogging without too much boring introspection on my part.
Thanks for visiting, and come back soon.
I actually coded a tool that does exactly the same thing about a year ago, and I've never released it. I'm not sure that it has quite the performance as the tool that Richard mentions (mine only checked about 30,000 passwords per minute, but it was running on a modest laptop), but I considered it "dangerous" just as well, so I sat on it. I even refused to give it to a fellow programmer, because I know how these sorts of things can spread -- you give it to someone you trust, and then they give it to 5 other people that they trust, and pretty soon it's available for download on 50 different Internet sites. The point is, I thought it was a tool that would be used for good reasons about 2% of the time, and for bad reasons the other 98% of the time, and I didn't feel comfortable with that.
For me, it just ends up being a difficult ethical question: if you write a useful program that will most likely be used as a damaging hacking tool, do you release it? I've heard some weak arguments by hackers who say that they write viruses just to force software companies to write better software, but I've always thought that was kind of bogus. Bruce Schneier has written several opinions on this and related subjects (the November 2001 issue of his newsletter is a good place to start), but even he just ends up taking an intelligent middle ground.
I wish there was a clear answer for questions like this, but I guess there's just not. In the meantime, please don't bombard me with e-mails asking for the password-cracking tool I wrote. You can write it yourself or buy it from the company that Richard linked to if you really need it.
1. Sholes intentionally separated common letter combinations and otherwise scrambled the letters on the keyboard in order to make people type slower, because his machines kept jamming.
2. In 1873, when Remington licensed (purchased?) the patent, they changed the layout of the keyboard so that the Remington brand name -- "Type Writer" -- could be typed quickly and easily using only the letters on the top row of the keyboard. In other words, it was a marketing ploy.
We'll probably never know what the real reason for the QWERTY layout was (although this site has a reasonable theory), so let's just say that it doesn't matter, because it is what it is. Whatever the case, this keyboard arrangement is confusing and non-intuitive, and the question is often asked: why is the QWERTY keyboard still in use, since there are other much more logical keyboard layouts available?
An article called Typing Errors, published in 1996, provides a fascinating discussion about that very question. I have quite often heard that the Dvorak keyboard layout (the most common modern QWERTY competitor) is much more intuitive and would allow people to learn much easier and type much faster and have a much lower chance of getting repetitive stress injuries like carpal tunnel.
At the risk of spoiling the end of the article, it turns out that this simply isn't true. While you would logically think that a keyboard layout based on statistical letter frequencies would allow you to type faster, the truth is that once your brain has figured out where all the keys on the keyboard are supposed to be, then all the different keyboard layouts have similar performance. Even though non-QWERTY layouts are intuitively better, in practice they're all the same. So why not use QWERTY, since it works just as well and it's already an accepted standard?
This ties in to what the article authors call "The QWERTY Myth". Apparently, the dominance of the QWERTY keyboard in the face of other "better" technologies is often used by economists as an example of how an inferior technology can rule the market, despite superior alternatives being available.
The fallacy there is that QWERTY isn't an inferior technology after all. At the user level, it happened to be just as good as anything else, and it was simply marketed well and had a large install base. Probably similar to a lot of computer technologies that we use today -- things don't have to be "better" than the competition per se, they just have to avoid being considerably worse. Beyond that, users will get used to whatever they end up with.
The book/author really seems to focus on sales teams, making the point that in a complex sale you have to have a coordinated sales team to be effective. "Coordinated" is key, because all the members of the team have to be in sync with a common strategy. "Team" is also important, because you need several different types of people to address all the angles that are involved with a complex sale. Not only are you dealing with technical people, financial people, middle managers, and upper-level managers, but you're also using multiple sales techniques to push your product, such as:
You might have one person who has multiple roles in those situations, but ultimately you'll need to have a team of people addressing the issues, not just a single salesperson.
I'm in the middle of doing some technical product evaluations right now, so I could really relate to a lot of what I read. Here are some additional insights that I can offer from the standpoint of a buyer/evaluator of technical solutions (I've done many rounds of technical product evaluations in past years). These aren't from the book, just from my personal experience.
1. If you're selling something to me, give me a single point of contact to go through. I can't stand when I'm dealing with a sales team and I'm not sure who to talk to, or I ask something of one person and then a week later someone else from the sales team has no idea that I had an issue or a question about something, and I have to bring it up all over again. I think there should be one person who coordinates all the pre-sales communication, and I expect that person to keep their sales team on the same page. Now, that's not to say that I shouldn't be allowed to talk to your technical people, just that there should be some clear and apparent coordination going on.
2. Respond to me quickly when I have technical questions, and offer to call me if I need clarification. I often have deadlines for the answers you give me. If it takes you forever to help me with my problems while you're actively trying to sell me something, I can only assume that it'll take even longer after a sale is made. Also, make sure that your responses are in the form of an e-mail, because I'm probably going to need to refer back to them at some point (and you shouldn't trust me to take good notes).
3. Give me links to technical information about your product, not a bunch of marketing documents. PDFs that the marketing department came up with are good for my managers, but they don't help me make any technical decisions. I want code samples and demos. If your product does something really cool, then show me that functionality and explain how I could do it, don't just talk about it.
4. If something is going to cost me extra, tell me upfront. If you don't, you're going to screw up my budget and that's going to make me look bad. Along those same lines, if you demonstrate a really nice feature of your product, you need to be willing to either give me or sell me (at a fixed and known cost) the programming required to implement that feature. Don't show me a really whiz-bang interface and then tell me later that it's just an internal template and I'll probably have to hire 5 senior developers in order to figure out how to reproduce that functionality. That will also make me look bad in the end, and I won't be a happy customer.
5. No matter what kind of relationship we already have, don't assume that I'm going to buy your product. I can't stand going to a presentation where the sales reps figure that something is a slam dunk and they don't prepare or they just have a "wink wink, nudge nudge, know-what-I-mean" kind of attitude. All that does is leave me unimpressed by a product that I thought I liked.
6. Don't try to impress me by talking on your cell phone during every free minute you have. That doesn't impress me, it annoys me. If you want to impress me, turn your phone off before you meet me and don't turn it back on until you leave. Pretend like you're taking me on a date -- would you whip out your cell phone and call your friends every time I happened to stop talking for a second?
7. Don't ask me for org charts. If you want to ask me which managers you should talk to and how to contact them, that's fine -- it actually makes me feel like you're asking my opinion about something if you word it correctly, and I can politely refuse if I want to. But I get really suspicious around people who walk into my office and ask me for an org chart (especially if I've never met them before).
8. Don't treat me like I'm unimportant just because I'm not an upper-level manager. I get questions every day about whether or not your product can do something, and I'm involved with the ultimate technical recommendation, and if you treat me like I work in the mail room then I'll probably subconsiously advise against your product. A little respect, please. I may turn out to be more important than you think.
Also, I have a little piece of advice for people in my position (doing technical evaluations) who have to decide between a technology that's already in-house and a competing technology that you're thinking of using: if a sales team from the competing technology company is involved with the decision-making process, then you should also involve a sales team from the company that supplies the existing technology. Otherwise it's really not fair to the technology that you already have. That happens all the time though, and you end up with a very one-sided sales pitch. Besides, if you bring in the sales team for your existing product, you may find out that that it does more than you think it does.
I've also made some observations over the years about the internal technical desicion-making process itself, but I think I'll leave that for a future entry. I've talked enough for now. Have a good weekend...
Also, if you've ever wondered exactly what "meme" means, the first few paragraphs of the article do a good job of defining it.
I thought this was fascinating, because I normally think of open-source software (OSS) projects as little mini-communities of dozens of developers who are spending all their free time working on code modules and IMing back and forth and whatnot -- you know, the Cathedral and the Bazaar, and all that. Well, the author of this article (one Sandeep Krishnamurthy) did a little statistical study of a batch of OSS projects and came to these conclusions:
Thinking about those findings (and Sandeep makes a few more good points in the Discussion of Findings section of the article too), they actually make sense, but I guess I've never thought about it before. Most of us probably envision Linux as the model of an open-source project, but the number of people involved there and the organization of the participants is the exception, not the rule. The level of participation in the Notes OSS (oops, I mean OpenNTF) projects is probably about par for the course.
When it comes down to it, most open-source projects are probably just an idea that one person has come up with and done 90% of the work for, and then a handful of other people might pitch in the other 10%. That's why project ideas on a site like OpenNTF so often fizzle out and die -- there's no concrete basis for the project in the first place, just someone saying "this would be a really cool thing for someone else to program for me". The successful projects have usually been mostly or completely coded before the project has even been initiated, and then a project gets put into place so that other contributors can help with the finishing touches.
By the way, there are several other very interesting articles that are worth reading (even if you don't end up agreeing with them) on the First Monday site. Unfortunately they're pretty long, so you'll want to reserve a good chunk of time to really sit back and read them. Content is Not King and Hacking Memes are two that you might want to take a look at. If I get a chance, I might discuss one or both of them in another entry sometime...
