Have you read the very next article, the one I link in the final sentence? There I explain my way to solve this apparent dilemma.

There are other cases that are trickier, and can’t be usefully analyzed purely in design terms. You have to look at the question in business terms, because in the end the decision to refactor properly or hack egregiously is a cost-benefit question, not a technical one.

In many projects, we can ignore the business side: revenues and costs are approximately stable, cash reserves are ample, the relationship between features and revenues is unclear, and both features and products are expected to live indefinitely. Given those factors, we can generally get away with only thinking in design terms.

For startups, though, none of those is true, which means we have to be more careful about when and how we indulge our preference for beautiful code.

I’d postulate that ideally, we just throw away the module with the code for that feature, and the rest of the code stays untouched.

For that to work, we need to refactor the whole system so that most of it doesn’t need to know a bit about multi-accounts. And those changes should be high-quality. Even when we throw away the feature, we still benefit from those refactorings, because the code improved in terms of SRP, SCP and OCP. We are likely to benefit from those changes in some way for future features, possibly in surprising ways.

I conclude that the quality of the one experimental module, that we can plug in and out on a whim, then might actually be of secondary concern.

What do you say?

One thing they’ve noticed is that some users have more than one account. (For example, I have a professional one, @williampietri, and a personal one.) The question they’d like to resolve: are enough users excited about multiple handles per account to make it worth a major system change? Or should they stick with what they have? It could be a major feature for top users and businesspeople, or it could be a dud.

So they do a quick experiment, taking a week to wedge in some multi-handle stuff. It’s pretty hairy hackery, as good chunks of their system assumed 1:1, not 1:N. But they tell their A/B framework to show it to 1% of the users, and they seed it to some of the known multi-login people too as an exclusive alpha test.

After 2 weeks, it turns out that their users don’t care much. The general population shows little interest. And even current multi-account users who thought they wanted the feature aren’t excited when they see it in practice. So they split the few joined accounts, send out a we’re-sorry email to the handful of users, and rip out the hack. There are a few places where they made the code better along the way; they keep those changes.

Now there’s no denying that they skipped some refactorings that might make the code better in a design sense. But as I said in the blog entry, this isn’t a software development project; it’s an attempt to discover a sustainable business. So the question isn’t about good design in the abstract, it’s whether spending the capital necessary to improve the design is the very best use of their very limited capital.

I think what makes people uncomfortable about this is that the answer is a very tactical, “It depends.” Extreme Programming tells us to always turn that quality dial to 11, to always be extremely sustainable. For typical software projects, I think that’s still good advice. But it’s not always correct for startups.

I certainly agree that some throw-away code will go faster when you make use of some of the quality-oriented practices we Agilists love. If I think of a good name for a variable, I’m not going to call it x just to save 0.05 seconds of typing. If some chunk of code is tricky enough that I’ll go faster writing it with a few tests, I’ll write the tests.

But for code that may last from a few days to a few weeks, I don’t believe all of our quality-oriented practices are always necessary, or even wise. For example, I’m sure you’d agree we shouldn’t do a major refactoring to properly accommodate a core domain change that we may strip out a week after release. Instead, we can hack something in with a UI-level integration and see whether the new feature is worth the work it will take to do it right.

I’ll have more to say on this in upcoming posts, so stop back. Or you can subscribe in your favorite feed reader via the upper right corner of this very page.