Drupal 7: Get Real, Get Dirty, and Get It Done
Yesterday I participated in the Drupal 7 code sprint with a host of excellent people. We made good progress and also talked about the state of the Drupal 7 release. Apparently Moshe and I came to a very similar conclusion about what needs to be done and both decided to blog about it; in fact I stole the title of this post from him.
Drupal 7 has been in development for 2.5 years. The good news is that we are finally, finally reaching the end. As I write this, there are only 8 open beta blocker issues (to be fixed before beta release) and 28 open critical issues (to be fixed before Drupal 7.0-RC1). That's not a lot.
The bad news is that pretty much all of these remaining issues are hard. For most of them, we think Drupal as it currently exists is wrong in some way, but we actually do not know or agree on what we think is right, or we do not know how to implement the behavior we want in a suitable fashion, or we think the behavior we want is impossible so we're trying to figure out the best compromise. Issues in this category often tend to be the most interesting, because all good engineers love struggling with difficult problems. They are also often the most emotionally charged. We all want Drupal to be perfect in every way, and we have invested so much personal effort that we all tend to feel very strongly about getting everything just right (whatever that means).
It is precisely at this point in the lifecycle of a new product that it is both most important, and most difficult, to understand the difference between what I will call (at least for this post) Engineering and Product Development. Engineering is about building the best system we can. Product Development is about building the best system we can ship on a reasonable schedule. To ship a product, sometimes we have to give up on what we think might be the Right Solution(tm) to a hard problem, either because the right solution would require too big a change at this late date, or we aren't sure the perfect solution even exists, or it would just take too long to get it done and tested.
For Drupal, a critical issue is defined as a bug that renders the system unusable or causes a security vulnerability. We need to take that definition to heart: only problems that make Drupal 7 essentially useless to a majority of people are truly critical enough to hold up the release any more. When evaluating a critical issue, or a proposed solution to a critical issue, ask yourself these questions:
* Am I over-valuing the importance of this issue because I am so personally vested in seeing it fixed?
* If this problem remains, is Drupal 7 really unusable as a result?
* Can we fix this problem by telling the user or site administrator, "Don't do that"?
* What is the simplest possible solution to the precise problem we're having, even if it does not address the hypothetically "larger issue"?
* What is the simplest possible change that may not fix the problem but will at least make Drupal 7 no longer unusable, thus downgrading the issue below critical?
Certainly, some issues really are critical and really do need to be fixed the right way, even if it is hard. Just remember: Drupal 7 has been in development for 2.5 years. We need to ship it. Don't let the perfect become the enemy of the good.