RSpec my authority!

I just read an interesting post titled Is Refactoring Worth it for Startups? The basic premise is that refactoring - the art of improving your code's design - might be very costly if your code isn't worth improving in the first place. I've oversimplified it, but hopefully you can understand the idea. There's no sense wasting time improving something that has zero dollar value.

Over the past couple years I've grown to be very fond of refactoring. That post though made me think hard about how much refactoring I currently do at my job. I can honestly say it's not that much.

When I built, launched, maintained and sold my website from scratch, I did a lot of refactoring in the process. That's mostly because from the very beginning it was just a fun project. I enjoyed spending some extra time pushing the design around, trying various things. It was a good learning experience.

Working at a startup is a different experience as you might imagine. We need to get features done, and we need them quickly. The top dawg always says "make it work, then make it clean...if there's time." Very rarely is there time - like a lot of startups, we've got plenty of development work to keep us busy for the next several months.

I think that when it comes to refactoring, startups have three choices:

1. Do very little or none and have their code fall into disrepair
2. Refactor mercilessly and spend lots of precious time on potentially worthless code
3. Use techniques and tools that minimize the need to refactor

(3) is where Rails comes into play. In my experience, infrastructure code tends to be a lot messier than domain code. We can spend a lot of time modeling the domain, both through dialog and coding. While it's still abstract thought-work, we hold a concept in our mind which just "makes sense." Infrastructure is different in that you usually have to think about what it does rather than what it is. I'm certain others disagree, but for me, analyzing an abstract concept is much easier than the abstraction of a fleeting action. All this boils down to me being more likely to get my domain code right, or closer to right, fairly early on. I spend much more time refactoring infrastructure code than I do domain code.

If this is the case, then it's obvious how Rails mitigates the need to refactor. By taking care of nearly all of the infrastructure, Rails lets me spend most of my time writing domain code - the code that I understand better throughout the process, thus have less need to refactor. Not only that, but when I do have to refactor, it's a lot more likely to be on code that genuinely has business value.

Using Rails is a giant step towards writing leaner, more maintainable apps. There's another thing you can do to reduce the time you spend refactoring.

Consider the meaning of refactoring once more:

Do we have any special design-related tools at our disposal? We're talking about Rails and the web here...

I'm talking, of course, about REST. REST is an architecture, a design decision you apply to your app as a whole. If you make a commitment to this simple, powerful, flexible design from the getgo, then it leaves you less room to make design mistakes.

Less room for design mistakes means less time spent cleaning up after yourself.

A while back I asked myself how you quantify the benefits of REST, and couldn't come up with anything. I've just known that it feels right and that my code is easier to write and maintain. Now though it's pretty simple to quantify the benefits. Using REST, you can spend more time adding features and less time reworking code which may turn out to be worthless.

Now all of this may seem that I think refactoring is a costly task. Nothing could be further from the truth. All I'm asking is what if we could make it a costly task? If you could come up with the perfect design after 5 minutes at the whiteboard, surely you wouldn't waste time refactoring your code. Why not look for ways to reduce refactoring time in the first place?

It really all comes down to decisions. Every decision we make is another opportunity to make a mistake and cost time, money and effort. Some of the decisions have enough potential upside that it's worth the calculated risk. Using Rails we can eliminate a lot of low-business value decisions that are still rampant in PHP and Java land - what directory structure to use, how to name things, how to structure controllers and actions, ORM configuration, etc. We get rid of the decisions that add little or no business value, and write the code that adds the most value. Exactly as software development should be.

REST takes it a step further by making design decisions for us as well. This works because we're limited by the constraints of the web. Even a very complex web application is far simpler than other apps and software systems. We can get away with committing ourselves to such an easily-overlooked design principle. I think the web is the perfect development platform for this very reason. Simple constraints give us less to worry about, so we can spend most of our time creating business value.

Ultimately I don't spend a lot of time refactoring because I simply don't need to. My team's design isn't perfect, but by starting simple and keeping it simple, we keep it really easy to maintain. The power of Rails, the elegance of Ruby, and the simplicity of REST combine to make most changes take only minutes (I'm known for getting moody if I spend two hours on a single task). Because of the tools and techniques we use, we're able to quickly add lots of functionality while at the same time reducing the risk of change.