Jared's Weblog

Main Page - Books - Links - Resources - About - Contact Me - RSS

Jared Richardson Most Popular
Help! I've Inherited Legacy Code
Testing Untestable Code
Continuous Integration... Why Bother?
Mock Client Testing
The Art of Work
Technical Idiot Savants
Targetted Skills Aquition vs Free Range Chickens
The Habits of Highly Effective Developers

Blog Archive

Mon, 17 Oct 2005

What's your UI?

As a developer or tester, you realize that a bad UI can ruin a product. No matter how good your product is, if you don't present it properly to the user, the product is perceived poorly. Maybe even cancelled.

If you write installers and your code is chugging along, installing all the bits properly, but your UI appears frozen, people assume the appliation has locked up. Same for data analysis or even web browsing. Feedback is vital.

We know this as an industry. We have UI specialists. We have user interface guidelines in larger companies. The look of a product is vital to it's success.

So, to be crystal clear, as an industry we know that a good UI is essential to a product's success.

So why don't we treat ourselves the same way?

I'm not suggesting we all apply for eXtreme makeovers, but I am suggesting that many people in the technology field give no thought to how they are seen or percieved.

I'm not talking about physical appearance, although that can be a part of it. There are many aspects to presenting yourself well.

Today I'm thinking about speaking well. Your ability to communicate clearly impacts your job, whether you are interviewing, pitching a project, or leading a daily meeting.

Many of us consider our technical jobs as crafts to be honed. How many of us realize that proper speaking just another tool in our toolbox? How many of us take time to hone that part of our craft?

How do you hone your craft as a speaker? One great way is ToastMasters. ToastMasters is an international organization dedicated to helping people learn how to communicate better. They present it more as public speaking but it's the same concept. The idea is to teach you how to present your ideas so they can be understood.

Even if you only attend your local ToastMasters for a few months you'll learn some important things.

There are people who work every week to improve themselves. They are honing their craft. (Are you?)

You'll learn the value of short learning exercises to improve yourself. (They don't read about talking. They don't talk about talking. They talk.)

Just listen to the feedback for each talk and you'll also pick up some valuable speaking tips. (Sounds like a code review, doesn't it?)

Lastly, let me point you to Alan Hoffler, a ToastMaster and also someone who's helped me with several presentations. He's started a blog with practical speaking examples and tips.

You can find his blog here.

So... when's the last time you polished your UI?



posted at: 20:21 | path: | permanent link to this entry

A Rails IDE

I've not used it but it's based on Eclipse and sounds very interesting. They are looking for testers. Anyone interested?

Check out radrails.

It really is amazing how much mind share Rails is getting these days. If you haven't checked it out, you owe it to yourself to give it at least a cursory look.


posted at: 19:49 | path: | permanent link to this entry

Mon, 10 Oct 2005

Tests Rust

They really do. Think about it... when you first write automated tests, they work. They're cool and shiny. But then you get busy, so you don't run the tests everyday. Eventually, you don't run them every week. It's like the abandoned bicycle in the backyard.

Over time, the automated tests become something you pull inside to use at the end of your product cycle. They become release tests... at least, you hoped they would be. But something happened to those tests you left out in the rain. They don't run cleanly anymore. They've rusted.

What does it mean for a test to rust? In the best scenario they just squeak a lot. In the worst case, they won't run at all. But why?

First, the code being tested breaks. It happens. Developers are human. Since they aren't perfect errors occur. So you find dozens (or hundreds!) of breaks when you finally run the tests. Unfortunately, with that many failures, most people assume the tests are bad and ignore them.

Second, the tests and the code get out of synch. The two need to march in lockstep. If the test doesn't know what the code is doing, it can't test the response. So again we have massive numbers of failures that get ignored.

Finally, trust fades over time. If your tests haven't been telling the developers anything useful, why should they listen to them? Trust is earned over time, not tossed over the fence at the end of the cycle. During the end of cycle, when everyone is stressed and busy, then you run the tests. Even if the tests only have a small number of failures, the developers will ignore them.

The only way to keep your tests shiny and new is to use them. Run them.

How often should you run them? I'm glad you asked. :)

Assume your test has a basic value of V. I can't tell you what your tests value is. That depends on your product and your test.

But I can tell you that over time V can degrade. Every time your code is touched and the tests aren't run, you lose value. In fact, if a test run is R and a code change is C, the formula is (R/C)*V

You start with the basic value of the test but you'll lose value if you only run the test every 10 code changes. You'll lose more if you only run every 100.

So if your test has a value of 10 but you only run it every 10 times the code changes, you have an effective use of (1/10)*10 = 1. However, if you have a really simple test with a value of only 1 but you run it every time the code changes, it's value to you is (1/1)*1 = 1.

The only way to maximize the return on your testing investment is to run your tests as often as possible, preferably after every code change.

The best way to do that? Continuous Integration. Add software that will build and test your product every time your code changes. It's not as hard as you might think and the pay off is tremendous. There are lots of products available to help you out.

Don't spend all that time on your tests just to see them rust.


posted at: 23:56 | path: | permanent link to this entry

Sat, 08 Oct 2005

On sale at Amazon

Amazon seems to have messed up the pricing for several of the Pragmatic Programmer books and their loss can be your gain. :)

If you've been thinking about picking up a copy (or an extra copy!) of Ship It! you can pick it up this week-end for $14.25 instead of the normal price of $20.

Mike Clark's Pragmatic Project Automation, the CVS book, and the C# Unit testing book

Remember, Christmas is right around the corner and wouldn't any grandparent just love to find a copy or two of Ship It! under the tree?



posted at: 12:22 | path: | permanent link to this entry

Fri, 07 Oct 2005

Some tools I use...

Sorry the blog went dark the last two weeks. Work's been very busy and we've had some sickness in the house... nothing serious, but nothing fun either. I thought a fun way to ramp back up would be to link to a few of the tools I've found useful recently and then add a few quick blog links.

Visual Thesaurus This tool was invaluable when we were writing Ship It! and I still find myself going back to it from time to time. In fact, I used it tonight. The interface is just amazing. They offer a free trial as well. Hit the URL and type in a word. After a few moments you'll see a visual representation of the words grouped by similar meanings. Invaluable when you're trying to figure out how to say something just right.

NVU is a great HTML editor. They bill themselves as "the complete web authoring system for Windows, Mac and Linux". I've only used it on Windows and Linux and it works great. I use it for any non-trivial HTML.

Dia is a program to draw diagrams. Reminds me of Visio. The Windows version is here.

The Gimp This is the a great (and free) image manipulation program. I'm no graphics guru so I can't speak to it's advanced features but it's great for the types of simple edits I need to do for presentations. It does take a lot of horsepower though... it's the reason I just upgraded my wife's box to one AMD's dual core chips!

Speaking of the dual core chips... wow! My desktop is a dual Opteron and my wife's dual core is just as responsive. If it weren't for the hassle of reinstalling everything, I'd probably sell my desktop and upgrade. I'm still amazed at how inexpensive her box was... at Best Buy no less. I'm waiting for the dual core laptops to start shipping. I've found press releases that say the laptops will show up in October.

As you've probably noticed, there are no code tools listed here today. Recently I've been working on several presentations and I haven't had any spare cycles for code. Hopefully that will change after Atlanta.

For those who've missed it, the Pragmatic Ajax book is in beta. I love the cover. If you're working with Ajax, buy the beta and tell the authors what you need. How often do you guys like Justin Gehtland writing to your spec?

Also, Jeffery Fredrick had a great a great blog entry called Ruby, Rails and Eclipse. (See? People read your blog!)

I'm going to try to post about how automated tests rust in a bit... but first I've got to go edit a few slides. :)



posted at: 21:10 | path: | permanent link to this entry