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.

Yes, I am well.

1. I left the botique enterprise content management software consulting company, Technology Services Group. ^[1]
2. I joined FeedBurner, as an engineer in February.
3. I did some really cool ad serving optimization code. My IE degree let me do some fun multivariate linear regressions to prioritize ad serving into their feed ad network. The code base was great to work in. Plus the team was great and I’ll really miss them. This leads to #4.
4. Thanks to the Chicago PHP users’ group, as well as my Chicago tech event calendar site Techsocial, I was able to attend php|tek. The presentations are now available. ^[2]
5. Google acquired FeedBurner in July. I don’t have much to say here, other than I learned a ton living through the acquisition process.
6. Meanwhile, I incorporated a side business that I’ve been working on since 2003. It’s been profitable since the launch in September ‘06. The entity is Second Valley, Inc, but I”m operating under another name. ^[3]
7. I pretty much had the perfect opportunity to ramp up my business by working on it full time. I’ll spend a few months at marketing, product development, (more) SEO, statistical analysis enhancements, and rebuilding the PHP app in Ruby on Rails.

Notes:

I went to the ACM Reflections Projections conference this weekend. There were top speakers, including the co-founder of Paypal, Max Levchin and the co-founder of YouTube, Jawed Karim. Here are some highlights from their talks.

Max Levchin: co-founder of Paypal.com and current CEO of slide.com

Millionaire Before Graduation: Entrepreneurship in the Post-Post-Bubble Internet

Speaking to an audience of undergrad and graduate students at UIUC, Max stressed if you’re an entrepreneur:

“You should start a company right now.”

But what is an entrepreneur? And what if I don’t have an idea yet?

“An entrepreneur is someone who desperately wants to start companies. He or she doesn’t even care what they are about, or which one.”

The important thing is starting. Max says you’ll never get it right the first time. So start now. Fail a few times while you are young. Paypal was Max’s fifth company. He started his first in his Junior year in college, and every one that wasn’t successful taught him what had to change for the next time.

When you start, the idea is cheap. It’s okay to be mostly interested in starting the company. Some people say in starting a company it is 90% hard work. No, says Levchin:

• 40% is hard work.
• 50% is having a great team

When you start a business, start it on the web. Why?

• It’s really cheap
• You get really fast feedback

However, don’t start selling something to enterprises. Enterprise sales cycles are slow, expensive, and require loads of salespeople. (You don’t want salespeople on your team early on either. Just tech people.) Make things work, and satisfy your direct-to-consumer audience.

Once you’re up, you need to record metrics on everything. Obsess over all of your data. You’ll discover the pages people actually use is different from what you expected them to use. Iterate. Bring what people use to the front. If you’re still in school, take lots of stat classes. It makes the metrics easier.

Remember you will fail.

Failure is your true test. It’s really good to fail in the beginning… If failing anytime is good: now is best. [So get to work and take risks so you’ll fail, so you’ll learn, so you’ll succeed!]

Tenacity is number one. You must be willing to fail 10 times for success in the 11th.

When you’re succeeding and you need to monetize, Levchin has three strategies:

1. Advertising - with Google Adsense, and other ad networks
2. Premium Subscriptions - this is tough though if your competition has these too, and you end up competing on price
3. Memberships - monthly, yearly, etc.

Jawed Karim: co-founder of YouTube and current masters student at Stanford

YouTube: From Concept to Hypergrowth

Jawed is the 2004 UIUC CS graduate who, after a 5 year tour at Paypal, co-founded YouTube. 19 months after launch, YouTube is one of the most-visited sites on the web.

• More than 100 million videos are served daily.
• A new video is uploaded every second
• The average user spends 30 minutes on YouTube per day

Prior to YouTube, what did video sharing look like? FTP uploads to a private website [or peer to peer] was the best way to share a video. People without websites and technical savy couldn’t share. Downloaders would have to download the full file, have the right codecs, and finally be able to view the clips. Discovering other related videos was not easy, and there was no way to post comments about a video you enjoyed. In 2004 the “Bit Torrent effect” emerged, which was scalable - but it lacked social aspects, simplicity, and was mostly for hard core geeks.

In 2005 Jawed and friends decided to create some sort of video sharing app inspired by Flickr and hot or not.

On Feb 14, 2005, work began.

We launched the site with a bunch of “stupid videos” … except no one one used it but ourselves. We pitched it to our friends. We wrote to all the Wired reporters (no replies). We talked to lots of VC’s (they didn’t call back.)

By May 2005, it was very frustrating. 50-60 videos were uploaded. They had an idea:

We posted an ad to the San Francisco Craigslist asking for girls to post videos to YouTube. If we thought they were attractive, and they posted 10 videos, we would send them $100 via Paypal.

No girls responded.

In June 2005 YouTube got revamped. “Related Videos” was added, to make the site more sticky. And instead of Jawed and co-founders spamming all their friends, they added a button “Email a friend” so the visitors could do that for them. Everything was changed to encourage user interaction. Make people want to spend more time on the site.

August 2005, YouTube gets Slashdotted. Things started taking off from here. The community did things they never expected. People would leave video responses to other people’s videos. So they created the Video Responses product. Pretty soon they had $3.5 Million in capital from Sequoya, and then you all know about the Google acquisition.

One lesson Jawed pushed home was:

Just because experts reject an idea does not mean it is a bad idea! In certain areas, there are no experts.

If you’re out there creating innovation, you may be the expert.

As we look for the next big thing, Karim suggests it will explode from newly emerging secondary technologies. Start a company that will make something that was previously difficult, easy.

And expect failure. Jawed worked on numorous other projects that failed, before hitting big with YouTube including a geographic aware IM client that grew to about 50,000 users before he pulled the plug. An interesting article about him, as the silent YouTube partner, may be found here.

Update 10/28/2006: A video of Jawed’s presentation is now on YouTube, watch it below:

I’m getting really excited for the upcoming No Fluff Just Stuff conference (November 17-19 in Chicago near O’Hare). At a recent Mobile Monday event, Neal Ford said he will be giving his Productive Programmer presentation at NFJS. I’ve seen the slides (pdf) and was impressed.

The whole pitch of the NFJS conference series is to pull in awesome speakers and authors, cap attendance at 250, and make it on a weekend so only the die-hard tech people come out. Many conferences or seminars have more marketing fluff than I can shake a stick at (I’m thinking of a recent Sun SOA talk I attended), so I hope this is different.

In preparation for the conference, I’m reading the NFJS Anthology 2006, a series of a couple dozen chapters written by the speakers. So far I’ve been impressed. Scott Davis had a chapter on Real-World Web Services, and Neal Ford has an excellent chapter on DSLs and Language-Oriented Programming (the next big thing after OO).

Here’s the schedule, has anyone attended NFJS before? I’ll be attending with someone else from work, so we plan to split up and go to different sessions, then having a mind meld on Monday. Shortly thereafter, we’ll be giving loads of presentations at work, which will then make their way to this blog.

I’ll be attending the ACM Reflections Projections conference (Techsocial link) this weekend. The speaker lineup looks impressive. Thanks to AJ Arora for inviting me.

Reflections | Projections brings together students and professionals from across the country to gain a broader perspective on computer science. The conference is a unique opportunity for attendees to enrich their knowledge of cutting-edge concepts from beyond the classroom. /blockquote>

The speakers include Joel Spolsky (huge blogger), Chris DiBona (Google), and Jawed Karim (co-founder of YouTube). I look forward to speaking with Jawed about the Google acquisition, seeing how I want to build a software company too.

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.