The Importance of Good Tools

I saw a review today of a blender that struck me as an important reminder in having good tools.

One day at Costco my wife and I were going past one of those product demos where a salesman wearing a headset a-la-Madonna was showing off a blender. As we stood and watched I commented to my wife about how all of these people were just waiting to try a smoothie, and that there was no way this guy was going to get one of these suckers to pay $350 for a blender. A BLENDER. But who walked out with one? You guessed it.

Well, we also bought it because the guy reminded us about Costco’s liberal return policy. So for the next month, we used it…and used it…and used it. Each time, I’m thinking, $350 for a blender! But man, this thing is an incredible MACHINE. It made short work of blending anything and everything we’ve ever put into it.

First, most likely a great sales job from the sales rep. Did you know that they are outside vendors and not Costco employees? The thing that clenched it for the gentleman was Costco’s return policy. I use a guarantee every day in my online marketing efforts and in my hypnotherapy practice. Having essentially no risk is comforting for people and generates huge amounts of sales.

Second, this man is like most people when confronted with a great tool without having any knowledge about why they need it yet. They don’t see the benefits of owning a great piece of equipment to do a job. A superior programming language, a better saw, a maintenance-free computer, a great car, and yes, even a great blender, can enhance your experience and make the work you do with it amazing.

We use it every single day, often multiple times. Some times it is only for simple little chores that could have been done with a lower powered tool, like mixing up a mocha, but this thing is quiet on low speeds, and a barracuda at high speeds. I once believed that a blender only needed two speeds: off and high, because that’s pretty much all anyone ever uses, but I’ve changed after using the 10 variable speeds on the Vitamix.

This is a common reaction from someone who discovers nuance in their tools and work. It is at this level of mastery of a task and tool that fine distinctions of 10 different speeds come in handy. Only a few short days before, he couldn’t distinguish that level of precision and why he would use it.

Ultimately, I decided that though it’s $350 when you use something EVERY day, usually multiple times a day, and that tool works really, really well and you actually enjoy using it, it’s probably worth it. My previous $45 blender that I once thought was pretty good now sits gathering dust. I’m spoiled now.

People often wonder why experts buy such high quality tools when many times a simple one will do the work, but this gentleman has nailed it. When you use something that often, you notice things others don’t. It’s not about being spoiled though, it’s about having the distinctions of quality that come with continued use of a tool. A $45 blender isn’t bad, per se, but it just doesn’t have the range of use in the skilled hands of a user.

I have hesitated to send in this review because of it’s considerable expense, but it truly has been one of the most quintessentially cool tools that we’ve bought. I think anyone who uses a blender regularly, or might, will find this to be the best blender they ever own. Well worth the savings in time and grief over the less powerful, less tough brands.

And there we have it, savings in time and grief. My time is worth considerably more than what I pay for good tools. The best of tools only make you better at what you do, saving you time (money) and grief (time, or money).

So where does this leave us? Pay extra attention to your most important work. Things that you do often, things that cause you joy, things that give you the most out of your day. Then look at the tools you use to do that work, nay art. Could they be improved? Is there something out there you know is better? If there is, seek it out and try it for a while. ASK for a liberal return policy or some other type of guarantee if there isn’t one already. The best tools and people stand by their work. They give you a guarantee not because they fear things will break, but because sometimes it’s the only way to get people over their own fears and give the best a try, changing them forever. It’s a high mark to hit, but only the best ever get there anyway. Take the leap, get good tools for the work you do.

http://www.kk.org/cooltools/archives/005318.php

Pretend You Are Leaving Tomorrow

Jonathan Rasmusson wrote a great post reminding us to Pretend you are going to be there forever.  His post is really great for contractors who mostly just come and go.

What works equally well is to pretend you are leaving tomorrow.  It’s a great exercise if you really do think you’ll be at your company for a long time and will have to maintain the software you create.  If you’re leaving tomorrow, what would you fix, document, clean up, or write tests for?  Who would you be nice to? We used to call this the “Hit by a bus” effect, but some people liked to use “the lottery winner” effect as the name. It really helped people get that they had to maintain their systems better and not become bottlenecks and share information.

Let’s see if we can make it a bit more general so that everyone can use it.

“Invert, always invert.” — Carl Gustav Jacob Jacobi

If you haven’t heard of Jacobi, you should check him out. Anyway, basically, all you have to do is think of the opposite of whatever position you are in. Have lots of time? Now pretend you have little. Have lots of people? What if you only had a few? Have only a little money? What if you had a lot? Stretching the constraints in your projects can really help you see new solutions. It’s helped me solve problems countless times for myself and my clients.

Are There Bones In Your Fish?

I went to lunch today to a nice restaurant in town and got something I have never had before: a salmon burrito. The meal tasted pretty good and I was having a good time with friends when I felt a small bone in my mouth, so I took it out. I thought to myself, “Well, it was an honest mistake, no big deal.” A few minutes later, I bit into another small bone. That was it. I was done with my meal. The important part though, is that I was done with the restaurant, probably for life. From two bones.

How often do you think about the basics? If you’re not executing perfectly on the basics, how can you expect to be executing at any higher level? Two bones in my burrito and you lose me as a customer for life. That’s potentially thousands of dollars. You might lose other customers at just one. Those bones just became pretty damn expensive for you. Quality is not just free, it’s money in the bank.

Of course, I’m not just talking about burritos and bones here. As your customers get more educated on what you do, they’ll begin to notice those bones. They’ve noticed them before, but just couldn’t pinpoint them. Now they can. What are you going to do?

Checklists

One of the main duties I performed as a consultant was kicking off a project for a new client. The process went by many different names. Iteration zero, project kickoff, inception, and QuickStart. Sometimes a combination of them.

The thing I learned right away was that there was always plenty to think about and set up. All projects are different of course, but all projects are also the same in many ways. So, I began to do what I always do in a new situation and make a checklist.

I learned this skill a long time ago and it has served me well in many different ways. To my clients, I seem to have a super memory and intellect. Combining the checklist with GTD helps greatly. To my colleagues, I can share the list and get feedback and improvements for my own projects and help theirs. Now on with how to create your checklist.

First, I almost never start from scratch. I look to those who have done it before and have learned lessons the hard way. Nobody is smart enough to think of everything, and besides, why duplicate work? Look to retrospectives, post mortems, project wrap ups, lessons learned, bug reports, lawsuits (yep…), API versions, forums, email lists, etc. Anything where people are seeing 20/20 after something went well or, more importantly, something went wrong. Put it all on the list without filtering. If you don’t have stuff written down somewhere, try interviewing people and listen to their war stories. You’ll learn some good lessons. Write. Them. Down.

Second, once you have your list, try organizing it by rough topics: architecture, project management, QA, analysis, client relations, contracts, etc. This is a good time to take the list to your coworkers and ask them to fill in areas that you’ve missed. The important thing to remember is to keep things on the list unless they are incorrect. This list is for all projects, not just “your” project.

After you’ve created your checklist, put it somewhere it can be seen and used as well as collaborated on. A wiki is great for this because you can have multiple editors and you’ll get to see all of the versions. Tell people where it is and have them use it. Asking for feedback on how it works is a great way to get them to use it. They’ll improve things and add new items as they come up.

At this point, you’re probably expecting an example or even full version of my checklist. Sorry. That would rob you of the experience of creating it yourself which is well worth your time in just the collaboration alone.

Initially, people will complain that your checklist is too long. Ignore them. Explain that the checklist is there to keep them safe and spending a 30 seconds or a minute on each item on the checklist will save them loads of time and mistakes later.

One last thing. The checklist is a great tool to make sure you haven’t forgotten anything, but it isn’t a substitute for critical thinking. The checklist will help you to not look dumb, but you still have to be smart. Good luck.

DSLs and Friends

My friends and fellow ThoughtWorkers Michael Schubert, Jay Fields, and Stephen Chu were just complimented by Martin Fowler.

This isn’t to say that there’s no benefit in a business-writable DSL. Indeed a couple of years ago some colleagues of mine built a system that included just that, and it was much appreciated by the business. It’s just that the effort in creating a decent editing environment, meaningful error messages, debugging and testing tools raises the cost significantly.

What Martin doesn’t go on to explain is that this project vastly improved efficiency for a whole organization.  They went from a situation where it took months with dozens of programmers to change some business rules in their software to minutes with all sorts of extras they couldn’t get before like “what-if” simulations.

Jay wrote about some of the things they learned in this presentation on InfoQ and much more on his blog about DSLs.

via MF Bliki: BusinessReadableDSL.

What’s Your Exit Strategy?

An occupational hazard of being a consultant is that you get to see lots of the same problems in many different organizations.

It seems that sometimes little thought is given to how an organization can move from one technology to another or to move from legacy systems (where legacy means it doesn’t fit the organization anymore) to better solutions.

Today’s decisions can be tomorrow’s botleneck or bad design. It’s just a matter of time.

What can you do to help your future organization? Things like SOA can help. Great tests around your application are essential if you ever make the choice to change.

I’m looking for something better. I don’t know if you can ever get to a system that is that responsive to change. I’d like to see one that is.

PSA: Don’t Generate Offensive Promo Codes

OK folks, I’m now on my 3rd client having problems with certain four letter words coming up in their automatically generated promo codes. It’s easy to get around this problem in a very simple way: Don’t use vowels in your promo codes if you’re using letters. No need for special filtering software or huge lists of banned words. You can always add complexity later, but that simple rule will help you more than the rest.

If you want to get more careful, you could alternate letters and numbers, or use some other strategy. To be kind to your users, be aware that some numbers and letters look the same to people and they will enter your codes wrong (or worse, enter in someone else’s code by mistake).

To help you, here’s a list of the numbers and letters I suggest people use because they won’t get them confused with each other and hopefully your system won’t create any bad words (if they do, let me know). If you’re worried about the number of combinations you can make, just add more characters to the length of your code or allow yourself the option to generate your own special codes.

letters = [‘B’, ‘C’, ‘D’, ‘F’, ‘H’, ‘J’, ‘K’, ‘L’, ‘M’, ‘N’, ‘P’, ‘Q’, ‘R’, ‘S’, ‘T’, ‘V’, ‘W’, ‘X’, ‘Y’, ‘Z’]
numbers = [2, 3, 4, 7, 9]

You could then take this and make a simple ruby method that does something like this:

letters = ['B', 'C', 'D', 'F', 'H', 'J', 'K', 'L', 'M', 'N', 'P', 'Q', 'R', 'S', 'T', 'V', 'W', 'X', 'Y', 'Z']
numbers = [2, 3, 4, 7, 9]
promo_set = letters | numbers # combine arrays
promo_code = promo_set.sort_by{rand}[0..14].to_s # randomize array and take the first 15 elements and make them a string
=> "CS4FZLHVMPK3QJN"

Mingle Tip: Search Mingle Projects Directly In Firefox

Do you love using Firefox’s built in Google search? Wish there was a way you could do that with your Mingle projects? Well, now you can with the code below.

I’ve provided a download of the xml file here.

You’ll need to edit the file to point to the Mingle project you want to use the search tool with and then you need to install it into your searchplugins directory for Firefox, which for Windows is probably something like

C:Program FilesMozilla Firefoxsearchplugins

and for Mac is something like

/Applications/Firefox.app/Contents/MacOS/searchplugins/

Drop the xml file in the folder and restart Firefox and you’ll have your new Mingle search up and running. It should look like this

Note: I’m working on getting this to work as described in this mozilla dev article for Mingle. It shouldn’t be too hard since we can modify views in Mingle. I’ll blog about it if people are interested.

PSA: Tab Between All Controls On Mac

I normally love the Mac’s design decisions, but one thing that’s always maddened me is that by default you can’t tab between all controls on webpages, etc. I finally got that fixed today with an article from lifehacker.

Click the “All Controls” radio button at the bottom of the Keyboard & Mouse pane in System Preferences to right this wrong.

Bliss.

[via]

When Distrust Turns To Disdain

While taking computer science classes in college, I was taught to distrust a user’s input in all cases. The theory goes that a user’s data can’t be trusted because it could be malicious or just a simple mistake that causes your program to have an error with input it didn’t expect. So you protect your system from incorrect user input and sanitize it. It always felt like one of our dirtier secrets to me, however I fully advocate the practice in code.

My problem comes when the people building software turn from distrusting their user’s input to having a level of disdain for the users themselves. It starts innocently enough with the engineering principles I described above, but can sometimes turn into small things like, “Our users won’t understand that,” and starts to slip into things like, “Our users are dumb, so we won’t do that.” If you’ve started to hate your users, you’ve gone too far. If something is too complex for your users to understand, it’s your job as the developer/engineer/analyst/etc. to make it so that they can understand it. If you think of your users like idiots, your system will reflect that and they will notice.

If your job is to design software for people to use (which, is pretty much all software), make sure you work with the user, instead of against their best interests.