Usability is a very important aspect of building great software. No matter how great the backend of your software is if it doesn't look good and isn't usable users aren't going to
love it.
Good usability can help your users kick ass.
One of the problems that I've run into over and over again when working as part of agile teams is how usability fits into the process. Usability engineering doesn't jive with agile. Most usability "experts" that I've dealt with expect to have a nice long design phase where they can consult the usability wizards, create "intergalactic" visio documents, and consult customers. After a couple weeks they come out of their room with an extremely nice interface that has every "i" dotted and every "t" crossed.
Of course when working on an agile team you don't have weeks to design every aspect of the interface. You also don't have weeks to review all
Jacob Neilson's usability writings. What you do have is an hour or two to think up some ideas and sketch them on a sheet of paper. You also have the freedom to come back to the design and tweak it to get it closer to what your after. And perhaps most importantly you have the ability to get your interface in front of customers sooner rather then later.
Why aren't "typical usability folks" agile fanatics? Isn't the principles behind agile software development what they're after? Isn't continous delivery of their interface to customers and the chance to get real users feedback on the interface what they're after? Why aren't more usability folks
like the folks over at 37signals?
Coda Hale has a great post entitled Six Ground Rules for “Rails Sucks” Articles which was written in response to this lovely argument for why Rails sucks.
Although his six rules are targeted at “Rails Sucks” articles I think they can go for pretty much any technology. I can’t count how many times I’ve seen similar arguments for other technologies. Just because you don’t understand or fully grok something doesn’t mean it sucks. Until the System.Magic namespace is written by Microsoft don’t assume technology X is going to magically do everything you want and desire.
As a software developer I naturally have dreams of one day starting my own software company where I get to build great software day in and day out, and makes loads and loads of money.
A couple weeks ago I picked up Bob Walsh's
Micro-ISV: From Vision to Reality. I think the first paragraph on the back cover sums up who the book is targetted at.
"This book is for every software developer who is fed up
with working for someone else. All over the world, and especially all
over the Internet, developers today are launching self-funded start-up
companies. And they're succeeding like never before."
The book takes the reader through the stages of starting a Micro-ISV, and provides helpful guidance and advice along the way. Each chapter has very valuable side-bars where Bob interviews those who have already done the Micro-ISV "thing". The sidebars were the highlight of the book for me as they provided real world people talking about real world problems that one encounters when starting a Micro-ISV.
Along with the valuable side-bar interviews the book also contains a bunch of helpful information about:
- Deciding on a product and developing your vision for the product.
- How to develop software as a Micro-ISV. I was glad to see talk about using good software development practices such as TDD, Source Control, and a good bug tracking application.
- How to present your product. Topics included getting on the "cluetrain", as well as how to develop a good user experience to customers of your website and online store.
- What type of corporation to start, how to get things done (with some plugs for Bob's MasterList Professional software), and other government related information.
- Focusing on the customer while marketing, supporting, and growing your business.
- Why you should both fear and embrace the 900 lb gorrilla named Microsoft.
The book concluded with a very valuable chapter full of interviews with emerging, successful, and very successful Micro-ISV's. As expected this was my favorite chapter as it talked about a diverse group of Micro-ISV's who were having varying degrees of success building their companies.
All in all I enjoyed the book. Since I had already done a good amout or reading on the topics in the book there wasn't anything earth shattering, however, it did do a very good job of bringing together a lot of the information that would be of interest to those thinking about starting their own Micro-ISV. So if that sounds like you,
go pick it up.
Kathy has an
interesting post on her
Creating Passionate Users blog about how performance reviews typically lead to mediocrity.
Maybe instead of working on our weaknesses, we should be enhancing and exploiting our strengths? What if the price for working on weakness (and who even decides what is and isn't a "weakness"?) is less chance to be f'n amazing?
She
suggests that be focusing on our "areas of improvement" we end up
becoming more mediocre. If instead we focused on how we could be "f'n
amazing" we could gain much more benefit. Would you rather be well
balanced or f'n amazing?