After my last post, a good friend of mine and all around brilliant guy, Paul Tagliamonte, told me that the advice I was giving was, well, wrong. Now the thing about brilliant people is that they tend to still be brilliant people, even when they disagree with you. In fact, when a really smart person disagrees with you, it’s far more likely that it’s because you are wrong, than because they are suddenly being dumb.
So, that being said, when Paul told me I was wrong, it most definitely gave me pause to think. And it’s been a rather long pause, actually, since he wrote this post immediately after reading mine, but it’s taken me a week to work out how exactly I wanted to respond to it. In the end, I think he’s right about most of what he said, but I also think he misunderstood what it was that I was trying to say. So this isn’t so much a rebuttal of his post, as it is a clarification on my original in light of his criticism.
Paul, as well as some folks who left comments, seemed to take my advice to mean that people shouldn’t care about how to make things better. But I like good things, so I’m certainly not going to tell people to settle for making mediocre stuff, or else I’d only have mediocre stuff to use. So I’m just going to come right out and say it: If someone tells you how to make your stuff better, then you definitely should take their advice and make it better! But here’s my caveat to that: Make it better in the next version, not this one.
I’m a firm believer that version 1.0 of anything is essentially a throw-away version. You have to get through that to really understand what was right about it and what was wrong about it, then you make version 2.0 which, while not perfect, is going to be quite a bit better. But you’ve got to make that 1.0, and actually release that 1.0, before you will really be able to make 2.0 good. So do 1.0 your way, and take the advice you get from people who are smarter than you and make 2.0 that much better.
If you hold back 1.0, if you never make that release and get that project out there, then no matter what you call the re-write, it’s still going to be your 1.0, which means you’re still going to need to do another version before you really start to get it right. Paul even alludes to this in his post, making an exception to his standards for projects “pushing for a 1.0 before anything else”, and I think he does this for the same reasons I’m advocating JFDI for 1.0 releases.
The majority of Paul’s post discusses the necessary qualities that a good patch, or really the qualities that any contribution to an existing project, should have. And while I absolutely agree that submissions to a major project should meet a high standard before being included, I don’t think that you should keep your work to yourself until it’s reached that level. Not mentioned specifically in his post, but something we discussed on IRC, was that Paul has been waiting on submitting a major set of patches to an upstream project because he doesn’t feel that they meet the standards they should before they are included. However, he’s not keeping them to himself either, he’s released them in a way that others can try them out now, even if their quality isn’t where he wants them to be. This is, essentially, his 1.0 release of that patch. He knows it’s not the best he can do, he knows how to make it better, but he’s also not holding back the work he’s already done, because that work still have a positive value that other people can realize now, instead of waiting for a a marginal gain in quality later. So here, again, I think we both agree.
So while I stand behind my initial suggestion that you should just do what you think should be done, I definitely don’t think that you should stop there. Nor should you continue to do things the way you want against the advice of others, especially when they do know more about it that you. Instead you should take their advice, take feedback from users, learn from both your success and mistakes, and make 2.0 even better, because 2.0 is where things really start to matter. 1.0 is just something you have to do before you get there, and you’re most likely going to throw it out no matter how long you spend re-writing it.