Jamie Zawinski is what I would call a duct-tape programmer. And I say that with a great deal of respect. He is the kind of programmer who is hard at work building the future, and making useful things so that people can do stuff. He is the guy you want on your team building go-carts, because he has two favorite tools: duct tape and WD-40. And he will wield them elegantly even as your go-cart is careening down the hill at a mile a minute.
[…]
And the duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.â€
You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work. So they sheepishly go along with whatever faddish programming craziness has come down from the architecture astronauts who speak at conferences and write books and articles and are so much smarter than us that they don’t realize that the stuff that they’re promoting is too hard for us.
Oy. How closely this parallels the sysadmin world! It’s interesting to see unique and cool frameworks come together in these amazing bread-slicing-new-wheel-building-ultra-rad panaceas that get things done. Assuming you have time to complete them. One of the things I’ve had to force myself to learn is what I’ve termed “rational perfectionism in technology”. Otherwise known as “Is it good enough? Ship it!”
It’s a difficult thing to accept, I know. As a geek, sometimes it just kills me to let something go out that isn’t up to the uber-high standards I generally have. But, sometimes you just have to. You’ve got a job to do and the customer is waiting on you to do it. Very often we will sit on something trying to achieve this golden-age of usefulness in a piece of software instead of taking a step back and trying to figure out if what we have now will work for the customer. It’s the technological equivalent to gilding the lily.
But many times we are faced with a task that cannot or should not be delayed if at all possible. Many times, it’s perfectly acceptable to put something out there that hits ony 80% of the need so the customer can start doing the job they need to do. From there, you can iteratively improve as necessary. And, more often than not, I’ve found that the customer is perfectly happy with that 80% solution and may not even notice the warts that you’ve laboriously fretted over.
An artist is never satisfied with his work. An art lover very often is.
Of course, we now approach this with the devil’s advocate voice in mind. I’m not saying half-ass the job. We should always strive to do our best when trying to give the customer what they want (or need). Just be balanced in it. It’s a constant juggle for me (which makes it kind of fun) to understand just where that technological center of gravity is and hover around it for as long as I can.
Just remember: just as you don’t knock the ducttape if it gets the job done, don’t knock the 80% mark if it makes your customer happy. Afterall, that’s why we’re here … to do what we can to help the customer.
-Update-
Joel’s post references the Worse-is-better concept. I thought this quote was rather interesting (and man do I agree with it …)
The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.
It’s perfectly possible to do the right thing first. You just need to break it into small steps, and ship a step at a time.
That’s a lot different from mediocre solutions, which is what Joel praises. Easily confused when you’re starting out work on something, but one will has better chances at being maintainable in the long run.