As developers and product owners, we often confuse quality and class.
“We need a quick and dirty version to try this all out”. This phrase is often interpreted as “Build a quick, crappy solution. Commit as many sins as you like. Just get me my features by Monday”.
As developers, we need to dispel the myth that sacrificing quality is a good method for getting quicker results. We should instead stress that if you want something fast, perhaps a solution of a different class is in order.
Quality and Class
A 2011 Ferrari GTO goes 200 miles-per-hour and does zero to sixty in about three seconds. It is awesome. It also costs about $500K. I’m not sure exactly how they’re made, but I’ll bet it’s at the hands of three or four grizzled master machinists in a stone building on a mountainside somewhere in Italy. I’ll bet it takes about 23 months.
The 2011 smart Car Passion Coupe might go 65 mph during strong wind gusts. It runs about $15K and is probably made by robots and extruded from recycled plastic shopping bags.
These vehicles are of two very different classes, but they share identical core features. They transport people, have reliable brakes, meet all safety standards, etc, etc.
My point is that when someone at smart USA said “Let’s make a really cheap car”, they didn’t build a car with a 400hp engine but bad brakes and no crumple zones. That would be sacrificing quality for the sake of class.
Instead they built a high-quality vehicle of a class that stresses economy over brute performance. I’d call it low-class, but that implies it’s bad or something. There’s all kinds of good-but-cheap-and-simple things. Think about that piece of Ikea furniture you bought eight years ago that’s still going strong.
Don’t Sacrifice Quality For the Sake of Class
When we talk about software features, we often ask things like “So do you want this to integrate with OpenID, Facebook Connect, and our own LDAP?” This is like asking “Do you want a Ferrari?” The answer will always be “YES”. Everyone wants a Ferrari.
Sometimes we’ll also say things like “Well, we can get it done fast, but it won’t be maintainable, and the next person who touches it will have a stroke when they see the code”. This is the same as promising a ultra-high speed car with shitty brakes.
What we should be doing is helping people understand that a good way to get quick results is to alter the class of the solution, rather than sacrificing quality.
Keep in mind that it’s OK for someone to want a high-class solution.
When the IPhone was first imagined, Mister Jobs probably declared aloud that it needed to be a game-changing device. He set a high bar for class, and that’s just fine.
Most often, though, we can do with something a bit less involved that the best CRUD system ever made. It probably boils down to having the discipline to always produce a high-quality product, even if its class isn’t top of the line.