I’m a ThoughtWorker. ThoughtWorks is changing the way that enterprise software is delivered. And with that we take firm stances on heavily debated topics. In previous jobs I’ve tried to push test driven development, unit testing, code coverage metrics, continuous integration… all controversial ‘best practices’. Results were mixed.

A few weeks ago I was at a large web 2.0 social networking site working with selenium grid automation. They were great clients, fully receptive to automated testing. Next week I’ll be heading to another leading internet company to work triage:

1. Work on troubled teams whose code is poorly tested
2. Enable groups to test legacy code
3. Attempt to spread a pervasive test driven mindset.

I’m joining a senior team of ThoughtWorkers and in preparation I’ve thought of various arguments I’ve heard (or used myself) against testing code. I’ll be challenged working with these very experienced people, but I am eagerly looking forward to the experience.

Argument #1

Adding all these tests only makes more code to maintain, debug, and write. This can’t be good - I want less work, not more!

Rebuttal: Would you agree code and requirements often change? Would it be valuable if something could automatically and accurately catch bugs introduced with changes? How about if the original developers are no longer on the project? Testing can enable less work — in a dynamically changing environment. Immediately the work is greater, but over time it is less.

Argument #2

Ok, fair enough, there are some good reasons to do this. BUT, when I want to change something later, I now have two points of failure - the code I’m changing, and all the tests that depend on that code. I haven’t really bought myself all that much security, because if my tests don’t catch the problem well, I’m just as hosed as if I had no tests. ^{Source: first comment from here}
Rebuttal:

1. You get better and faster with tests the more you write them.
2. By writing tests you further understand the business domain and craft a better thought out solution.
3. Whenever making changes in the future you actually have 1 + n points of failure. That which you are changing plus the other interacting systems within the code. By writing tests you will automatically catch the interactions, as well as the initial point of failure. Sure the tests need maintaining, but now with two things to maintain, you catch (almost all) these failure points.

Argument #3

I generally think testing is a good idea. But I’m stressed out, I’ll get to it later… tomorrow I’ll add tests… as soon as I get this working
Rebuttal: Take a page from Agile Software Development: Principles, Patterns, and Practices by Robert C. Martin.. He argues for refactoring but since the two concepts are so tightly entwined, I think the argument applies here:

“Refactoring is like cleaning up the kitchen after dinner. The first time you skip it, you are done with dinner more quickly. But that lack of clean dishes and clear working space makes dinner take longer to prepare the next day. This makes you want to skip cleaning again. Indeed, you can always finish dinner faster today if you skip cleaning, but the mess builds and builds. Eventually you are spending an inordinate amount of time hunting for the right cooking utensils, chiseling the encrusted dried food off of the dishes, and scrubbing them down so that they are suitable to cook with. Dinner takes forever. Skipping the cleanup does not really make dinner go faster.”

Skipping testing does not really make software development faster, because changes are guaranteed. (You’ll have to cook another dinner eventually). Without an easy way to baseline and build upon existing code, time is spent bugfixing that could instead be adding features or writing new tests.

Argument #4

I’m awesome. I don’t write bugs. So I don’t need tests.
Rebuttal: Great. I’m excited to be working with you. I’m sure I’ll be able to learn a great deal. I imagine you like fresh challenges. And in six months or a year this current project won’t be as interesting to you as it is today. In fact, you’ll be on to something more challenging and worthy of your awesomeness.

So that means someone else — possibly a junior developer — will be maintaining and working on this code. Without tests, they will be frequently seeking your assistance and guidance to prevent bugs. This is not what you want, is it? You want new challenges, not constantly being hassled by old code. So write the tests now to ensure your ego and intellect can move forward to bigger and better things.

Elaborating and paraphrasing, Neal Ford argued at eRubycon 2007:

Now I look at not testing as professionally irresponsible. I’m paid to create software, to deliver on a client’s business needs. If I don’t rigorously and automatically ensure I have accomplished this with the minimum amount of bugs — I am committing malpractice.

What arguments have you encountered, and how have you responded?

I’m migrating one of my main e-commerce sites from php to Rails. Coming from a few years of Java and php makes me really appreciate this framework’s rapid development cycles, as well as strict MVC approach.

Note: this is a technical post, it assumes you’re interested in, and familiar with Rails.

Rails wants to be RESTful. Many sites and books go into depth explaining REST. Last year’s Railsconf keynote by DHH can give you the big picture of CRUD and RESTful applications. (Be sure to follow along with the pdf slides, while you watch the video).

Look at an existing mature project (Beast) to learn how to make RESTful models

Nitty gritty RESTful implementation details have been hard to find. So I started searching out open source projects that are known for good design. And I read the code.

Beast is a forum program written in Rails by Rick Olson and Josh Goebel. Best of all, it’s a great example of a REST application.

I’m a visual person, so I created the chart below to help me get the hang of what the Models and relationships look like in Beast. Big bold squares are actual database backed objects. Dotted squares are just regular models.

Please contact me if you catch an error or omission.

Here’s how you use the diagram

Right now, browse here: http://svn.techno-weenie.net/projects/beast/trunk/app/models to the Subversion source of Beast. Back already? My you’re fast. Read over the different model objects. See how they relate. Think about what’s been abstracted into additional Resources, rather than creating actions willy nilly in the controllers.

Then check it out and run it in your local environment. Even if you couldn’t care less about the (quite nice) forum software that it is, it’s good to learn by taking it for a spin.

But I think I need more actions than CRUD gives me!

As DHH said in the 2006 Railsconf keynote, sometimes you think you need another non-CRUD verb to your controller. Say you have a Forum that has Users and Topics. Some users want to monitor topics. At first blush, you may want to add an action to Topic. You’d then post to /topic/monitor/123 to start monitoring topic 123.

There is another way.

Relationships, events and states can all be models. When a new topic is to be monitored, you’ll GET to /monitorships/new to get the new Monitorship object form. Then POST to /monitorships to actually create it.

Models are more than things.

In college I was fortunate enough to fly - and float - on NASA’s “Reduced Gravity Student Flight Opportunity Program” (R.G.S.F.O.P. for …short). Basically you get in an airplane and climb and dive from 24,000 to 34,000 feet. The peaks of this roller coaster ride create weightlessness… watch the video for an explanation and more.

Yes, this is a little off topic from my usual investing podcast. But isn’t this NASA program awesome? We showed this video to several hundred students in elementary and high schools. I think inspiring students to study hard, technical topics is a wonderful thing for any country’s educational system.

-JAW
I’ve been wanting to upload this for a year now, and I finally got to it. If you like what you see.. leave me a comment. I’ll post more videos. (-; And thanks to NASA, our many, many, many, sponsors, as well as Professor Tan!

CSS is something most of us in web development understand. But so many people still hate it. Why such an awkward response for something that makes sense after you get past the awkward tweener period? I love to teach. Especially tech. I just learn so much more that way. So here’s my CSS training for when you know css, but you want to connect the pieces together a little more.

At work we can have “Lunch and Learns,” where someone demos and astounds us as we happily munch on free food. I’ve done a few in the past, but now it’s time to ratchet it up. This is such an awesome (and underutilized) way to turn us into a consulting powerhouse. Goal: one lunch and learn per month as long as I’m working in the office.

Download:

• Zip file of the demos css tweener html css files lunch and learn.zip
• Powerpoint presentation css training tweener.ppt
• Pdf version of the presentation css training tweener.pdf

Or… look at some of my beautiful slides. Look what you’re missing if you don’t download the presentation.

Meaningful CSS

Meaningful Pages

The often misunderstood box model

Grab a cheat sheet

Get the css cheat sheet here

The coolest thing happened twice while I was teaching, I looked out at my coworkers, and every eyeball was looking right back at me rapt with attention. It may have been because I have the tendency to move a little too fast through examples, but I like to think they were really interested and I was doing an awesome job.

Teaching is the best way to learn. It puts me under pressure to stay ahead, and conversations during class bring out the tough topics we could otherwise overlook. Leading this Java class reminds me of taking Linear Algebra with all the math majors (which I was not). We would meet up in the library and use an old greenboard for hours discussing matrices and eigenvalues. I’d get hungry and want to stop, but the rush of trying to explain things to others propelled me. I nailed that class with a solid A.

For the next 16 weeks I’ll be teaching (and learning) the Sun Certified Java Programmer material along with my coworkers. To ace the exam, we’ll all need to turn ourselves into javac compilers.
From what I’ve read so far, Kathy Sierra and Bert Bates do an awesome job of helping you stay interested in this beefy reading material. I’d highly recommend the book.