Quality-vs.-Quantity

I recently (two days ago) came across a very interesting article by Jeff Atwood over at codinghorror.com which discussed Quantity of Quality, and why Quantity always trumps Quality.

I’ve written before about how trying to execute perfectly essentially leads you to standing still with nothing to show for it, and this still holds true. Is it better or worse to show something that’s poorly architected, but achieves its purpose, rather than a grand plan that’s still on paper?

When I started ReplyWire, and even now to some extent, I struggled with decisions such as choosing the right design pattern, am I doing this in the right language, this method is old school, I should switch to MVC instead of WebForms, etc, etc, etc.

Truth is, none of that matters! I thought and thought and thought, and had nothing to show for it. After losing a week or two, I threw my hands up in the air and realized, this is not an exercise choosing all the right tools and languages and designing it perfectly, this is an exercise in creating a usable prototype as quickly as possible.

So I used the methods I knew, old school or not, and in a week or so, BAM, had something tangible. I’m not going for “Best engineered SaaS platform”, I’m going for “Here is something customers will PAY for”. I’ll refactor it when I’m being paid to.

Look back to some of the experiences you’ve had. What impresses you more, a portfolio full of 100 different successful projects, or a portfolio full of 5 projects? Most of the time, we don’t even look at the quality when we come across large portfolios.

Go to another blog with someone who has 3000 posts, that’s pretty intense, but do you actually go through and judge each one? No way! How about a software company with dozens of logos of satisfied clients, tons of white papers, lots of blog posts…. Jeez, just writing that makes me believe in their abilities. (On brick at a time folks….)

On top of that, the more you do something, the better you’re going to get at it. Even if it’s wrong, the act of repetition allows you to iterate and improve your process.

Examples

  • Diving: While I was practicing for my PADI open water instructor exam, my friend Pete Jawork and I spent hours in the pool swimming in the shallow end passing a 10~20 pound weight back and forth. By the time the exam came, I could pretty much plant myself in 3 feet of water and not worry about hitting the bottom or breaking the surface.
  • Blogging: My first posts took me roughly an hour to write, each. This post is almost done at about 30 minutes. I’d like to get that down to 10
  • Programming: I’ve never really gotten in to Javascript, but now I have to. At first, I was really really bad, slow, and inefficient. As I kept writing and rewriting, I became a lot more competent using the language, and yesterday finished a complete rewrite of ReplyWire’s integration code in about 2 hours.
  • Life: Keep on living, you get better at it… 🙂

Point is, we all start somewhere, and it’s more important to just keep banging your head against a wall (and improving!), rather than standing there and looking for the best way through. Eventually the wall will give way, and over time, you’ll get better at knocking them down.

Oh and here is a great quote that’s total BS

Quality is more important then Quantity. One home run is better then two doubles

– Steve Jobs

Says the guy who kept trying and failing and had to rework and retool and redesign until finally the home run was hit. (Oh the Ipad is great and revolutionary? How about that Apple Newtown from the 90’s.. Swing and a miss!)

Yes, a home run is better, but you only get there but swinging over and over and over and over…………………..

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>