The Art of Quality

Speaker: Reid Peifer
Original Post: Sidways8

The subtitle of this talk is “More Awesome. Less Suck.” for those that want to know.

A little history on the speaker and his company.

The speaker is the author of The Events Calendar plugin, found here.

When they got started with the plugin they started looking at their competitors. There are free plugins, your peers and a 15 year old kid living in his parents basement. So, how do they compete? They offer quality, support and longevity. That is what helps to set them apart from all the rest.

They realized that they need to compete on quality.

Notes on Quality

So what does quality mean? It can mean beautiful, stable, simple, and extensible.

Quality isn’t a state of being. It starts before you write your first line of code and continues long after you get paid for what you do.

Process Promotes Quality

Their process:

  1. Spec – Write out what the thing you are going to build does. What problem will it solve? Who will use it?
  2. Wireframe – Mock up what you want to build. There are probably 50 ways to solve the problem you are building something to solve, and your first idea is probably not the best.
  3. Prototype – This is a wireframe in code. This helps to find the “gotchas” that didn’t get caught during wireframing. They use UX 4.
  4. UX Test – This can be as simple as asking someone you know to test it and using join.me to see how the person testing goes through your app. This can be really simple.
  5. Visual Design
  6. Development
  7. Documentation – You must document your work. Document for both developers and users.
  8. QA – Time to test on as many devices as possible. Test everything, log everything, then go and fix the problems. chiliproject.org, redmine.org, basecamp.com
  9. Security Audit – Its a good idea to find a security expert and pay them to look at your code.
  10. Performance Audit – Stop developing for a minute and actually look at what you have done.
  11. Beta – Ask people to check out your product. You can ask people from Meetups or through Twitter or whatever.
  12. QA
  13. Release

Keep in mind that once you ship your product to the public, that is the day that support starts.