Radyology

Dvorak Benchmark Redux

45 wpm with 4.1% accuracy

CITCON Rocks!

Just got back from CITCON Denver 2008, and it was fantastic. Two thumbs way up for the best 1 day conference I've ever been to. In fact, for the price (free), I'd say it rivals any other conference I've been to in the last year. Well worth the time and minimal expense, and I'll be pulling out all the stops to make it again next year.

In one of the open spaces, I was able to do a (very) abridged version of the presentation on Infinitest that I hope to give at Agile 2008. There's still time to offer reviews and feedback, so if you're interested in Continuous Testing, it's not too late to recommend its inclusion in the '08 program.

Infinitest v3 Released!

After months of work (and neglecting my blog) Infinitest 3 is finally ready for prime-time. There's been a lot of great improvements in this version, including:

• Automatic sorting of errors by point of failure, rather than by test
  
• New 'zero configuration' launcher
  
• Significantly improved test runner performance
  
• Regex-based filtering for tests
  
• Updated status and error messages
  

I'm really excited about this new version and I'm looking forward to presenting it at CITCON this week. So, if you're going to be there, look me up.

Continuous Integration Is A Hack

A recent discussion at SD West, revolving around Agile certification and the need for "Agility" metrics, ended up with me standing on a chair and ranting at the entire audience...

(Sigh)

When will I learn?

CI is one of many useful practices that Agile developers employ today, but fundamentally, it is a hack. That's because although it's very useful to know that I've introduced a bug 20 minutes after creating it, what I really want is to know the very second that I type the offending line in my editor. CI is just the best that we can do right now, given the technology that is at our disposal.

And that is why I will continue to rant and rail against any "Agile" certification that focuses on practices. As if checking off a list of best practices was the best way to learn and adapt. I'm sure at some point in the future, we will move beyond the need for CI, to something that solves the core problem more effectively. But an "Agile" certification that mandated CI hinders that search, because by adapting to a better approach, you no longer meet the standards of the certification. Inhibiting the desire to adapt and change is the very anthesis of Agile.

Agility is a set of values and principles...and no more. Practices depend on technology and technique, which can (and should) be constantly evolving. Values, on the other hand, address the fundamental issues raised when humans work together to create something, and that is truly what makes Agility worthwhile.

What does a light bulb teach us about Test Driven Development?

Electrical Engineering is a hobby of mine. Electronic components fascinate me, and I usually have a little EE side project going on just to satisfy my solder-lust.

Lately, I've been watching some of the MIT open courseware and one particular class has been getting most of my attention, EE 6.002: Circuits and Electronics.

One of the topics covered in this class is a EE principle known as the Lumped Circuit Abstraction. What the LCA does is assume that the current into a component, less the current out, is equal to zero. This makes modern electronics possible, because without it, you're left only with Maxwell's Equations to describe the flow of electricity. Trying to compute the flux over something as simple as a light bulb would be extraordinarily complex, even for the most accomplished engineer. The LCA simplifies Maxwell's equations down to a small set of laws, that anyone with a high school math education can apply.

Of course, the LCA does have a drawback. It assumes certain things that may or may not be true for a given object. In order to gain this simplicity, electrical engineers have to restrict their work to discreet components that fit neatly within the constraints of the LCA. Resistors, capacitors, transistors, diodes...all these components can be treated as a black box, and used to build systems that do interesting things.

Could EE's use components that don't fit in the LCA? Sure. And I would bet that in some very rare cases, they do. But these engineers have recognized that keeping system designs simple almost universally outweighs the benefits of making them more efficient, compact, cheaper to build, or whatever else a non-discreet component would buy them...because the cost of trying to design a system using only Maxwell's equations is enormous.

So what does this have to do with Test Driven Development? Often, you'll hear the objection that TDD is too hard because not all software is easy to automatically test. That's true. But at the same time, we have to make sure our software works before we ship it out the door. While an untestable component may be cheap to write, the net cost of creating and maintaining it is much higher.

So what do we do? The LCA makes it pretty clear. Don't build components that cannot be automatically tested. At first, this can seem pretty restrictive. However, experienced Test Driven developers will tell you that sticking to this rule actually helps improve their designs, because they're more naturally decoupled and cohesive.

So I think if you're objecting to Test Driven Development because you can't find a way to test the software you're writing, you've got it all backwards. I would propose that you're building the wrong components to solve the problem, and that you should consider using something that's testable. At a minimum, you'll eliminate the test/fix/test cycle that's likely occurring at the end of all your release cycles. You may actually wind up with a better design.

Dvorak Benchmark

Using the Dvorak layout...

After 5 hours and 18 minutes of total practice, 26 WPM with a 3% error rate. I haven't learned all the keys yet (about half), so this benchmark is taken using a subset. Still...I'm happy with my progress so far.

Dvorak benchmark

So, when re-typing "Common Sense" by Thomas Paine, using a QWERTY layout, I can type 41 words per minute with an error rate of 5.7%.

Lets see how much I can improve on that by switching to Dvorak.

The Need For Speed

I have a confession to make: I never really learned to touch type. Oh sure, I took the same typing classes in school as everyone else, but there was about a 3 year gap between those classes and when I got really addicted to computers. In that span of time, I sort of lost the skill.

Later, when I started writing lots of code, I also found that a lot of the keys I needed to hit (periods, parenthesis, slashes, and so forth) were a little farther away from the home row than I'd like. As a result, I grew up typing my own way. It goes a little something like this:

On a QWERTY keyboard, my two index fingers sit on D and K. This leaves my pinky fingers free to rest on the shift key (on the left hand) and the enter key (on the right hand). This also means my index fingers are hitting a large percentage of the keys (everything between D and K), and the rest of my fingers don't do that much work. Using this horribly hacky method, I'm able to type around 35 words per minute. Not great, but (up until now) good enough.

Lately, though, I've been doing a lot more with dynamically typed languages. Python and (more recently) Groovy, specifically. These languages are great, but one of the tradeoffs for greatly reduced code verbosity is that the editor you use can't help you quite as much. When programming in Java, usually the quickest way to type out a method name is to hit the first three letters, hit the shortcut for code completion, and wait a few hundred milliseconds or so for the editor to fill it in. But with dynamically typed languages, that feature isn't always available, because methods and properties can be added dynamically at runtime, and there's no way to know what might be there.

As a result, I've really been feeling the limitations of my home-grown typing method. And so I've made the decision to learn how to touch type...using the Dvorak keyboard layout.

Yes, that's right. Why go along with the crowd when you can be the one outcast in the room with all the vowels on the home row. In all seriousness, most sources that I've seen predict a 20% increase in speed, and a 50% increase in accuracy, when going from QWERTY to Dvorak. And considering I'll also be learning to touch-type, I expect to see a increase even greater than that. I've downloaded a really good typing trainer called Master Key, which seems to support Dvorak well, and I plan to use it for an hour a night. As soon as I've learned the entire keyboard layout, I'll start posting my WPM.

Nobody Wants Your Skanky Code

Everyone once in a while, you hear about a developer working in a shop with a draconian security policy. In these places, they don't have root access to their own machines, and it takes a call to the IT department to get even the most basic software installed. Internet access is highly regulated, and doled out on a "need only" basis. USB drives and personal laptops are strictly forbidden. Forget waterboarding, this kind of torture goes beyond all sense of decency.

To all you CTO's out there who think this is a good idea, read this well: If you don't even trust your employees enough to give them access to their own machines, you have nothing to worry about. Nobody wants your over-engineered, untested, skanky-ass spaghetti code. Nobody outside your organization could even understand it, much less steal it. The reason is, nobody in your organization cares about that code. You've made it clear that you don't care about them, and they're returning the favor by producing the most worthless product they possibly can. The most a potential thief ever do with it is glance through the source, scoffing at what he saw, and claiming that he could re-write it in 6 months. Take it from me, your Intellectual Property (ha!) is perfectly safe.

To all the CTO's who may be considering such a move, let me say this: Anyone in your organization who wants to steal your source code already has. They did it on their first day. The only reasonable recourse it to sue the pants off them if they try to distribute it.

Intellectual property isn't like gold...it loses value when it's locked away. Instead of spending lots of time and money instituting complex security procedures that slow people down and make them feel like criminals, why not hire some people you can actually trust, and give them what they need to get the job done?

Your Mother Does Not Code Here

What if we applied the unwritten rules of the office break room to our code?

Imagine, for a moment, the most disrespectful office worker of all time. He steals food from the office refrigerator. After greedily consuming every morsel, he leaves the dirty plates and discarded containers littered around the office. When confronted about his crude behavior, he explains that he "had to get some work done" and "didn't have time" to buy his own food or clean up his own mess.

This total disregard for the welfare of your coworkers would, at a minimum, gain you their contempt. Repeated often enough, it might even get you fired. And yet programmers around the world display this kind of behavior on a daily basis, creating a mess in something much more valuable than the company's break room...the company's source code.

When a software developer makes a mess in code to quickly complete accomplish a task, they're taking advantage of the rest of the team. Not only are they choosing a personal short term gain over creating durable value for the company, but they're also setting the expectation that this task can be completed in a shortened timeframe, which makes the responsible members of the team look bad.

Making a mess in code, and leaving it for others to clean up, is unprofessional. When it's done to advance your own interests this act borders on immoral. The only reason this crime is tolerated at all is that it does not occur out in the open for everyone to see.