reCAPTCHA: stop spam. read books.

This is really cool. reCAPTCHA is a free CAPTCHA service that asks the user to type two words. They know the first word, but the second comes from a failed OCR scan. If you get the first word right, reCAPTCHA assumes you’re human, and they store your answer to the second word…they even run it by a few other humans to raise the confidence. Not only are you authenticated, you’re transcribing. According to reCAPTCHA, “in aggregate these little puzzles consume more than 150,000 hours of work each day”.

[For the record, I don’t know anyone at reCAPTCHA. I found them while reading up on CAPTCHAs for work.]

In the new office!

My company moved its office last week — this is our first week at home in the new digs. My desk is against a great brick wall, and next to a window that actually opens! I have a great view of Talcott Mountain, which should soon start turning to fall colors.

My new desk The view

Shameless bragging aside, now that the move’s finished, I’m about ready to get a new post up. The next one will be about arguing (or debating) on the job.

Trying some agility

I had an interesting conversation with a co-worker recently. We got to discussing a small project we were on back in January ’05, that basically involved creating a small dynamic questioner. You configure the interview by creating questions, and each possible answer to the question leads to either another question, or an outcome. We modelled the interview as a directed acyclic graph (I know, you already knew about DAGs — the link is for the other readers). We built a test tool that traversed the DAG, and reported all possible paths. We even (this was pretty cool) built an importer that created interviews from FreeMind mind maps…basically made FreeMind our GUI. We did all this in about 3 weeks (Java and XSL, if anyone’s wondering). We had fun, and both our management and our customers loved it. It’s loads easier to change the questions now than it would’ve been if the questions were just hard-coded, the way everyone expected it to be done. I think we even beat the estimate for that approach.

Anyway. We realized the other day that our approach for that mini-project could be called agile. On the project, we tackled as much of the problem as we could understand, just trying to make things better. Dozens of special-case rules for which question is asked when? Let’s make that generic, and configure the questions. Redundant branches in that hierarchical question tree? Let’s optimize it into a DAG. Hard to write all that XML? Let’s use FreeMind for its nodes-to-XML interface, and transform it. Hard to test all 30,000-odd paths through this mess? Automatic tester. Build a little, see a little further, build a little more.

Now, I’m on a much larger, higher-profile project: replace our hand-grown portal (pretty cheesy) with a commercial portal product. How we implement the portal product will impact a lot of future development, since a number of other teams will be building for the portal, and learning from or building on our work. [This is what I’m hearing, anyway.] No one on the project has any experience with this portal product (horray!). After spinning my wheels a bit, I realized the only way we could get anything done was to start building, and find our way as we go. We need experience with this tool, we need scabs on our knees from falling down with it. So our approach this time will be more agile — more intentionally agile.

This makes my project manager a tad nervous, and with good reason, I think — agile isn’t what you’d call popular around the shop. Not that it’s been proven as a bad idea, it’s just that (I suspect) all these methods that emphasize coding and doing things without lots of up-front planning sound completely irresponsible to upper management. I think if I talked to some IT execs and said I had no concrete plan for implementing this portal product, they’d respond like my mom did when I said I had no concrete plan for getting through college.

But all that aside, we’re doing it anyway. It seems to me like the only real solution. I was encouraged when my manager (an ex-architect) said he’d be nervous if we weren’t doing it this way. What most surprised me about all this, though, was how easy it was to get everyone to agree. My PM is new to the company, my manager loves a good skunk-works project, the other developers on the project were interested — like all the stars aligned, or something. And to emphasize that effect, right after everyone agreed to it, I saw Raganwald’s post Just do it.

Letting the ego get in the way

One of Robert Glass’ Fallacies of Software Engineering is that “Programming can and should be egoless.” People think that ego gets in the way of writing good software — you need to be cool, calm, and collected. No room for ego here, thanks, we’re detached professionals. Glass, though, argues that ego is part of what makes a programmer good — it provides incentive, personal attachment, motivation. Your software reflects on you, so make it good. This is all fine, and makes some sense to me. However, I want to talk about another aspect of ego that I think is less discussed, and more of a problem.

Maybe I should start with an illustration. In a recent meeting, I was trying to understand the new requirement the customer was asking for. The BA, having a great business background but very little IT background, already understood the problem — and solved it for me. It took some polite work for me to find out for myself what the new requirement was about, so I could design an appropriate solution. Part of the new requirement meant that I’d have to interface with an existing enterprise user profile system that stores user groups in a hierarchy. The BA couldn’t understand why it had to be in a hierarchy — she kept saying, “look, can’t we just get a list of the users, and use that? It just seems easier to me.”

I think this illustrates a common problem. Customers who have limited IT skills will insist that you use the solution they came up with. When you hear someone say, “I just see this in my head…why can’t we do that?”, you’re probably facing this.

If you’re building a system, you’re working with someone who understands the problem that system should solve. I’ll just call him the customer, although I think sometimes, this also applies to business analysts. Whoever it is, he also has an ego (he’s human, isn’t he?). He has an idea, at some level, how the system should solve the problem, and this is where the ego gets in the way.

Now, if you write software for a living, then you probably have more experience building systems than this person does. It’s what you do. This person does something else, by definition. You’re probably better able to imagine complex systems, deal with complex algorithms and data structures, and foresee the consequences of different design or solution decisions. Not because you’re smarter than the customer, but because, again, it’s what you do.

But when a customer has an idea for a system, it’s his idea. He’s thought some about this, and brought you his idea to be implemented. The more he’s thought about it, probably the firmer he is about the idea. If he identifies with it, if it’s “his idea,” you’ll have a hard time making him see any of its flaws. On the flip side, if you suggest a solution that he can’t readily understand, it can scare him away. You get that look that says “what kind of whack-o would want to deal with something that complex?”

I guess this is one of those situations where you can’t fix it, you can only deal with it. But understanding that customers and BAs may have this kind of attachment can provide a lot of calm in these situations, and calm is the path you want to take.

Here’s a review of Glass’ Facts and Fallacies of Software Engineering that I just found, but haven’t read yet.

Why do they think “doing it right” means taking longer?

Often when I suggest a better way to do things, some kind of process improvement, people say, “I think that’s an excellent idea. Unfortunately, we’re on a very aggressive schedule. In a perfect world, I think your idea would be a wonderful way to do things, but we just don’t have the time now.” This is said about all kinds of reviews (requirements, design, and code), prototyping, usability testing, building strategically, unit testing…

I think the crux of this misunderstanding is this: “doing it right” is harder than “doing it easy”, and “doing it right” is something people made up because they’re nit-picks. It’s almost like etiquette — “In a perfect world, I would set the table properly, but I just don’t have the time. Tonight, to save time, we’ll eat off paper plates with paper towels.”

The problem with this is that these practices are meant to save time, effort, and money. Skipping them hurts, not helps. Skipping them actually creates the problem you’re trying to solve when you skip them! I say these practices are as superfluous as a doctor sanitizing his hands before he operates on me.