Skip to content

Paying Knowledge Forward

Sunday, November 22, 2009

The Food Network is the default channel on our TV. I think I enjoy food and cooking for the same reasons I love developing software. In both cases, you’re creating something where before there was nothing. You may be following a recipe, you may be trying something new, but in cooking as in software you’re creating something for other people to enjoy. I think that’s why cooking also appeals to many of my programmer friends.

Tonight I watched part of Jamie Oliver’s Ministry of Food. In it, the Naked Chef has a fantastic idea to improve the way people eat. Jamie travels to an economically depressed town and teaches ten recipes to ten people who have rarely (or in some cases never) cooked for their families. In exchange for Jamie’s knowledge these ten people each promise to teach the recipes and skills to two more people, who must promise to teach two more people, and so on. Jamie’s lofty goal is to create exponential growth in culinary skills for people that can really benefit from those skills.

Jamie’s plan is not a terribly new idea. It was even brought into pop culture in the 2000 film Pay It Forward. Jamie’s name for his project, “Ministry of Food” also isn’t new: it references a government organization created in the UK at the start of World War II to help people make the most of their rationed food.

I find Jamie Oliver inspiring for many reasons, but this particular show was especially inspirational because Jamie is teaching valuable skills to people who would otherwise not had the opportunity to learn them. This is a very close parallel to the part of my own work that I find most rewarding: teaching software development practices and skills to people who wouldn’t have the opportunity or tools available to learn them otherwise1.

Turning to chefs for inspirational ways to improve our craft is hardly a trail I’m blazing. In Thoughts on the Future of the Boutique Software Shop, Michael Feathers uses Gordon Ramsay (another of my favourite chefs) as his inspiration for talking about the paralllels between software development and the culinary world.

I feel that the software industry is a pretty broken down in many places, much like an economically depressed small town, but I don’t think it’s impossible to fix. There are very few, if any, people out there who deliberately write poor quality software. Many developers just haven’t had the opportunity to learn how to write software well. The problems in our industry are due to a lack of education2.

So, in an attempt to improve the software development industry as a whole I’m going to follow Jamie’s culinary lead, and employ the same method. From now on I’m going to make sure that in addition to posting my thoughts here for the world to see, I’m going to specifically reach out to at least two people who can benefit from the things I have learned. I will ask those people to reach out to two people and help them. I want everyone that learns something new to reach out to two people and share what they’ve learned, and ask those people to do the same.

Reaching out to two people personally does not mean blogging or tweeting. We already have that; it’s passive engagement. I want you to actively reach out to two people individually, and personally. Send a personal email, an Instant Message, or make a phone call. Better yet meet for a real chat! That way, we’re all helping each other. We’re improving the craft exponentially. And we’re having important and valuable conversations along the way. I think sharing knowledge can reasonably be considered part of Doing Your Damned Job.

To encourage this process of knowledge sharing, I’m going to start asking: “With how many people have you personally shared this thing you’ve learned?” I would like to encourage everyone else to do the same. I really hope this is something that some people will get behind, because I think it can work.

To get started, go and share an important piece of knowledge with two people. Tell them to share that knowledge with two people. Let’s make life better for everyone that chooses to be a part of this terrific craft.

1. An idea that I struggle with sometimes is that it’s not about opportunity, it’s about aptitude. I used to completely disagree, but I just finished working with someone who has convinced me that there are some people that are entirely beyond help. These people are in the minority, though. Most problems with software quality are due to ignorance, not stupidity.

2. Okay, and ego. But ego problems are just education problems for unwilling students. But let’s pretend everyone is as awesome as I am, and has the same lack of ego.

Filed in Development | | Comments

Test The Hard Stuff

Saturday, November 21, 2009

I am pleased to see testing taking a bigger hold in software development circles over the past few years. It is especially pleasing to see that TDD and BDD are really catching on as the best way to ensure that it’s done well. I’ve seen a lot of projects over the past few years, and the number that I see without an attempt at a comprehensive test suite is smaller every year. It warms my heart.

I often get introduced to a project with a very proud exclamation: “Not only do we have tests for everything, they were written first!” I’m sure most of you will understand that there’s not a lot related to testing Ruby that I’m likely to find new and exciting. Sometimes there’s a neat hack, or an interesting idea, but it’s inevitably variations on a theme I’ve been intimately involved with for the past 5 years. It’s not just because of my involvement, though, it’s because testing Ruby is the easy.

I don’t get excited when a team tells me they test drove their Rails application. I expect it. It’s part of Doing Your Damned Job. Testing Rails applications is a solved problem.

I often get excited by their enthusiastic proclamation of testing, though, and I ask hopefully “What are you using to test the JavaScript?”

“Oh, uh, well, you see, uh, we only tested the Ruby parts. Testing JavaScript is hard!”

My heart sinks every time. There’s a simple reason why, and I’m going to embolden it for you, because it’s important. If browsers still had a blink tag, the following would be an appropriate usage:

The stuff that’s hard to test is the stuff that needs it the most.

This isn’t just related to writing JavaScript in a web application. This is a universal truth. A very common reason why things are hard to test is that they’re tightly coupled and have really mucky dependencies1. If something is tightly coupled and has really mucky dependencies, your tests will shine a floodlight on them and provide you with a roadmap for cleaning them up.

When you test the Ruby parts of your Rails project, that’s great. I’m glad you’re making an effort to Do Your Damned Job. But if you rely on JavaScript (or other languages, for that matter) those parts need to be treated with the same care and attention that you paid to the Ruby parts. Testing part of your application is not Doing Your Damned Job.

Part of the problem with testing JavaScript is one of bootstrapping. Getting the testing frameworks set up and running can be combersome. Many of them are poorly documented, lots are incomplete, and some just aren’t that great. Why do you think that is? Because only a small fraction of the people are doing their damned jobs and building comprehensive software all the way down. Pick a framework, use it, and write about your experiences.

Consider a Rails application that has a beautiful test suite for all of the Ruby stuff and none for the JavaScript. You’ve tested the parts that interact with the database, the basic workflow, and the backend of the application. The stuff you left out is the stuff the user sees and interacts with heavily. Because of the tight coupling and dependencies, the stuff you haven’t tested is the most fragile.

Question: Is it most likely to break in front of the user because it’s JavaScript and JavaScript testing is hard, or is it most likely to break because you didn’t test it?

Answer: Your users don’t care.

If testing is part of Doing Your Damned Job (hint: it is) then it certainly includes testing the hard part.

So if you send me a Rails project that has nice comprehensive tests for the Ruby, and a hairy unmaintainable mess of JavaScript, don’t be surprised if I say “Hey, thanks for doing the easy part.”2

Watch this space for some notes from the trenches on testing the hard stuff.

1. This is especially true of JavaScript: it’s tightly coupled to the browser and the DOM, and the dependencies on both are mucky.

2. I probably won’t mutter “fucker” under my breath, but don’t be surprised at that, either.

Filed in Development | | Comments

Do Your Damned Job

Monday, November 16, 2009

I’ve heard the phrase “Developer QA” being thrown about quite a bit lately, and recently encountered it at work. Basically, when people talk about “Developer QA”, they’re referring to a developer ensuring that the code they’re pushing forward is of high enough quality to make it into production. Who could argue with that? Lots of people, it seems.

There is some disagreement about whether “Developer QA” is required, and I think it’s a language issue (read about my good friends Sapir and Whorf). “QA is not the job of the Developer; that’s why we have QA” sounds perfectly reasonable. Why should developers do someone else’s job? When using the phrase “Developer QA” the language suggests that Developers are given tasks from someone else’s job description.

However, I don’t think the suggestion in the language is the intended outcome. Certainly, ensuring that the code works is the developer’s job. (Feel free to disagree, but you’ll sound ridiculous.) So from now on, I’m not going to say, or enjoy hearing, “Developer QA”. I’m going to say “Do Your Damned Job.” I might even type DYDJ for short.

I’m not a big fan of negative reinforcement, but I am in full support of loud and critical commentary for every person that pushes a 500, blatant oversight, or other atrocity to QA. (Myself included; I pride myself on being my own worst critic.) When you do this, you are wasting your co-workers’ time, and that’s just not nice. They’re not going to invite you over for BBQ if you keep being not nice.

Writing tests is one very important way to DYDJ. On a project that has been well tested from start to finish, including a comprehensive suite of acceptance tests, I even feel comfortable pushing to QA without even looking at it in a browser. Few people out there will have code that is tested this well. If you have code that isn’t well tested, it can’t provide you with that level of comfort: You’re going to have to click through.

The bottom line is this: as a developer, it’s your responsibility to make sure your stuff works. That is not QA, my developer friends: That’s doing your damned job.

Filed in Development | | Comments

Absence Makes the Heart Grow Fonder

Monday, November 16, 2009

The title may be a tired cliché, but I don’t mind beating the dead horse when it amuses me. It’s been a long time since I sat down to write, and I’ve missed you all dearly.

I’ve been collecting a lot of thoughts and ideas, and it’s time to have a place where I can share them with the rest of the world again. Thanks to the good fellows at Disqus you’ll be able to participate.

It looks a little messy here, and that’s something I’m working on slowly. I’ve got a dozen or so half-written ideas in the pipeline, a series of exciting announcements, and hopefully some interesting thoughts to share. I hope you’ll find the link to “subscribe to the feed”, or return later.

As always, thanks for visiting, and please feel free to return.

Filed in Uncategorized | | Comments